egenskaber med Spring and Spring Boot

oversigt

denne vejledning viser, hvordan du konfigurerer og bruger Egenskaber i foråret via Java configuration og @PropertySource.

Vi vil også se, hvordan egenskaber fungerer i Spring Boot.

Registrer en Egenskabsfil via annotationer

Spring 3.1 introducerer også den nye @PropertySource-annotation som en praktisk mekanisme til at tilføje egenskabskilder til miljøet.,

Vi kan bruge denne annotation i forbindelse med @Configuration annotation:

@Configuration@PropertySource("classpath:foo.properties")public class PropertiesWithJavaConfig { //...}

en anden meget nyttig måde at registrere en ny egenskabsfil på er at bruge en pladsholder, som giver os mulighed for dynamisk at vælge den rigtige fil ved runtime:

@PropertySource({ "classpath:persistence-${envTarget:mysql}.properties"})...

2.1. Definition af flere Ejendomsplaceringer

@PropertySource-annotationen kan gentages i henhold til Java 8-konventioner., Derfor, hvis vi bruger Java 8 eller nyere, kan vi bruge denne annotation til at definere flere ejendomsplaceringer:

selvfølgelig kan vi også bruge @PropertySources-annotationen og specificere en række @PropertySource. Dette fungerer i enhver understøttet Java-version, ikke kun i Java 8 eller nyere:

I begge tilfælde er det værd at bemærke, at i tilfælde af en kollision med egenskabsnavn har den sidste kildelæsning forrang.,

brug af/Injektionsegenskaber

injektion af en egenskab med @Value-annotationen er ligetil:

@Value( "${jdbc.url}" )private String jdbcUrl;

Vi kan også angive en standardværdi for ejendommen:

@Value( "${jdbc.url:aDefaultUrl}" )private String jdbcUrl;

den nye PropertySourcesPlaceholderConfigurer tilføjet i foråret 3.1 løse ${…} pladsholdere inden Bean definition egenskabsværdier og @værdi anmærkninger.,

endelig kan vi få værdien af en egenskab ved hjælp af Environment API:

@Autowiredprivate Environment env;...dataSource.setUrl(env.getProperty("jdbc.url"));

egenskaber med Spring Boot

før vi går ind på mere avancerede konfigurationsindstillinger for egenskaber, lad os bruge lidt tid på at se på den nye egenskabsstøtte i Spring Boot.

generelt involverer denne nye support mindre konfiguration sammenlignet med standardfjeder, hvilket naturligvis er et af hovedmålene med Boot.

4. 1. ansøgning.,egenskaber: Standardegenskabsfilen

Boot anvender sin typiske konvention om konfigurationsmetode til ejendomsfiler. Det betyder, at vi simpelthen kan sætte en ansøgning.egenskaber fil i vores src / main / resources mappe, og det vil blive automatisk opdaget. Vi kan derefter injicere alle belastede egenskaber fra det som normalt.

så ved at bruge denne standardfil behøver vi ikke eksplicit at registrere en PropertySource eller endda give en sti til en ejendomsfil.,

Vi kan også konfigurere en anden fil ved runtime, hvis vi har brug for det, ved hjælp af en miljøegenskab:

java -jar app.jar --spring.config.location=classpath:/another-location.properties

Fra Spring Boot 2.3 kan vi også specificere wildildcard-placeringer for konfigurationsfiler.

for eksempel kan vi indstille foråret.konfigurationsfil.placering ejendom til config/*/:

java -jar app.jar --spring.config.location=config/*/

På denne måde vil Spring Boot søge efter konfigurationsfiler, der matcher config / * / mappemønsteret uden for vores jar-fil. Dette er praktisk, når vi har flere kilder til konfigurationsegenskaber.

siden version 2.4.,0, Spring Boot understøtter brug af multi-document properties-filer, på samme måde som YAML gør ved design:

baeldung.customProperty=defaultValue#---baeldung.customProperty=overriddenValue

Bemærk, at for properties-filer er notationen med tre bindestreger forud for et kommentartegn (#).

4, 2. Miljøspecifik Egenskabsfil

Hvis vi skal målrette mod forskellige miljøer, er der en indbygget mekanisme til det i Boot.

Vi kan blot definere et applikationsmiljø.egenskabsfilen i src / main / resources-mappen, og indstil derefter en Fjederprofil med det samme miljønavn.,hvis vi for eksempel definerer et” staging ” – miljø, betyder det, at vi bliver nødt til at definere en staging-profil og derefter applikationsstaging.ejendomme.

denne env-fil vil blive indlæst og vil have forrang over standardegenskabsfilen. Bemærk, at standardfilen stadig vil blive indlæst, det er bare, at når der er en egenskabskollision, har den miljøspecifikke egenskabsfil forrang.

4.3. Test-specifik Egenskabsfil

Vi har muligvis også et krav om at bruge forskellige egenskabsværdier, når vores applikation er under test.,Spring Boot håndterer dette for os ved at kigge i vores src/test/resources mappe under en testkørsel. Igen vil Standardegenskaber stadig blive injicerbar som normalt, men vil blive tilsidesat af disse, hvis der er en kollision.

4.4. @TestPropertySource-annotationen

Hvis vi har brug for mere granulær kontrol over testegenskaber, kan vi bruge @TestPropertySource-annotationen.,

Dette giver os mulighed for at indstille testegenskaber for en bestemt testkontekst, idet vi har forrang over standardegenskabskilderne:

Hvis vi ikke ønsker at bruge en fil, kan vi specificere navne og værdier direkte:

Vi kan også opnå en lignende effekt ved hjælp af egenskabsargumentet i @SpringBootTest-annotationen:

4.5. Hierarkiske egenskaber

Hvis vi har egenskaber, der er grupperet sammen, kan vi gøre brug af @ConfigurationProperties-annotationen, som vil kortlægge disse ejendomshierarkier til Java-objekter-grafer.,

lad os tage nogle egenskaber, der bruges til at konfigurere en databaseforbindelse:

database.url=jdbc:postgresql:/localhost:5432/instancedatabase.username=foodatabase.password=bar

og lad os derefter bruge annotationen til at kortlægge dem til et databaseobjekt:

Spring Boot anvender dets konvention over konfigurationsmetode igen, automatisk kortlægning mellem egenskabsnavne og deres tilsvarende felter. Alt, hvad vi skal levere, er ejendomspræfikset.

Hvis du vil grave dybere ned i konfigurationsegenskaber, skal du kigge på vores dybdegående artikel.

4, 6. Alternativ: YAML-filer

Spring understøtter også YAML-filer.,

alle de samme navngivningsregler gælder for testspecifikke, miljøspecifikke og standardegenskabsfiler. Den eneste forskel er filtypenavnet og en afhængighed af, at SnakeYAML-biblioteket er på vores classpath.,

YAML er særlig god til hierarkisk ejendomsopbevaring; følgende ejendomsfil:

database.url=jdbc:postgresql:/localhost:5432/instancedatabase.username=foodatabase.password=barsecret: foo

er synonymt med følgende YAML-fil:

database: url: jdbc:postgresql:/localhost:5432/instance username: foo password: barsecret: foo

det er også værd at nævne, at YAML-filer ikke understøtter @PropertySource-annotationen, så hvis vi har brug for denne annotation, ville det begrænse os til at bruge en YAML-fil.egenskaber fil.

et andet bemærkelsesværdigt punkt er, at i version 2.4.0 Spring Boot ændret den måde, hvorpå egenskaber er indlæst fra multi-dokument YAML filer., Tidligere var rækkefølgen, hvor de blev tilføjet, baseret på profilaktiveringsordren. Med den nye version følger rammen imidlertid de samme bestillingsregler, som vi tidligere angav for .egenskaber Filer; Egenskaber erklæret lavere i filen vil simpelthen tilsidesætte dem højere op.

Derudover kan profiler i denne version ikke længere aktiveres fra profilspecifikke dokumenter, hvilket gør resultatet klarere og mere forudsigeligt.

4.7. Import af yderligere konfigurationsfiler

før version 2.4.,0, Spring Boot tilladt inklusive yderligere konfigurationsfiler ved hjælp af foråret.konfigurationsfil.placering og forår.konfigurationsfil.yderligere-placering egenskaber, men de havde visse begrænsninger. For eksempel måtte de defineres, før applikationen startede (som miljø-eller Systemegenskaber eller ved hjælp af kommandolinjeargumenter), da de blev brugt tidligt i processen.

i den nævnte version kan vi bruge foråret.konfigurationsfil.Importer ejendom i ansøgningen.egenskaber eller anvendelse.yml-fil til nemt at inkludere yderligere filer., Denne egenskab understøtter nogle interessante features:

• tilføje flere filer eller mapper
• de filer, der kan indlæses enten fra classpath eller fra en ekstern mappe
• angiver, hvis start-bør processen mislykkes, hvis en fil ikke kan findes, eller hvis det er en valgfri fil
• import extensionless filer

Lad os se et gyldigt eksempel:

Bemærk: her er vi, formateret på denne ejendom hjælp linjeskift bare for klarhedens skyld.

foråret vil behandle importen som et nyt dokument, der indsættes umiddelbart under indførselsangivelsen.

4.8., Egenskaber fra kommandolinjeargumenter

udover at bruge filer, kan vi videregive egenskaber direkte på kommandolinjen:

java -jar app.jar --property="value"

Vi kan også gøre dette via Systemegenskaber, som leveres før-jar-kommandoen snarere end efter det:

java -Dproperty.name="value" -jar app.jar

4.9. Egenskaber fra miljøvariabler

Spring Boot registrerer også miljøvariabler og behandler dem som egenskaber:

export name=valuejava -jar app.jar

4.10., Randomisering af egenskabsværdier

Hvis vi ikke ønsker deterministiske egenskabsværdier, kan vi bruge RandomValuePropertySource til at randomisere værdierne for egenskaber:

random.number=${random.int}random.long=${random.long}random.uuid=${random.uuid}

4.11. Yderligere typer af Egenskabskilder

Spring Boot understøtter et væld af egenskabskilder, gennemføre en gennemtænkt bestilling at tillade fornuftig tvingende. Det er værd at konsultere den officielle dokumentation, som går længere end anvendelsesområdet for denne artikel.,

konfiguration ved hjælp af Ra.Beans — the PropertySourcesPlaceholderConfigurer

udover de praktiske metoder til at få egenskaber til foråret, kan vi også definere og regiter egenskabskonfigurationsbønnen manuelt.

arbejde med Ejendommensourcesplaceholderconfigurer giver os fuld kontrol over konfigurationen, med ulempen ved at være mere verbose og for det meste unødvendig.,

lad os se, hvordan vi kan definere denne bønne ved hjælp af Java-konfiguration:

egenskaber i forældre-barn-sammenhænge

dette spørgsmål kommer op igen og igen: Hvad sker der, når vores parentebapplikation har en forælder og en børnekontekst? Forældrekonteksten kan have en fælles kernefunktionalitet og bønner, og derefter en (eller flere) børnekontekster, der måske indeholder servlet-specifikke bønner.

i så fald, hvad er den bedste måde at definere egenskabsfiler og inkludere dem i disse sammenhænge? Og hvordan man bedst kan hente disse egenskaber fra foråret?

Vi giver en simpel sammenbrud.,

Hvis filen er defineret i overordnet kontekst:

• @værdi fungerer i Børnekontekst: ja

• @værdi fungerer i overordnet kontekst: ja

• miljø.getProperty i Børnekontekst: ja

• miljø.getProperty i Overordnet sammenhæng: JA

Hvis filen er defineret i Barnets kontekst:

• @Værdien værker i Barnets kontekst: JA

• @Værdien arbejder i Overordnet sammenhæng: NEJ

• miljø.getProperty i Børnekontekst: ja

• miljø.,getProperty i Overordnet sammenhæng: NEJ

Konklusion

Denne artikel viste flere eksempler på at arbejde med ejendomme og egenskaber for filer i Foråret.

som altid er hele koden, der understøtter artiklen, tilgængelig på GitHub.