streamalism.org

1. Oversikt

Denne opplæringen vil vises hvordan du setter opp og bruker eiendommer om våren via Java-konfigurasjon og @PropertySource.

Vi får også se hvordan eiendommer fungerer i Spring Boot.

2. Registrer en Egenskapsfil via merknader

Våren 3.1 introduserer også den nye @PropertySource kommentar som en praktisk mekanisme for å tilføre eiendomskilder til miljøet.

Vi kan bruke denne merknaden i forbindelse med @Konfigurasjon kommentar:

@Configuration @PropertySource ("classpath: foo.properties") offentlig klasse PropertiesWithJavaConfig {// ...}

En annen veldig nyttig måte å registrere en ny eiendomsfil på er å bruke en plassholder, som lar oss velg riktig fil på kjøretid dynamisk:

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

2.1. Definere flere eiendomssteder

De @PropertySource merknader kan repeteres i henhold til Java 8-konvensjonene. Derfor, hvis vi bruker Java 8 eller høyere, kan vi bruke denne kommentaren til å definere flere eiendomssteder:

@PropertySource ("classpath: foo.properties") @PropertySource ("classpath: bar.properties") offentlig klasse PropertiesWithJavaConfig {// ...}

Selvfølgelig, vi kan også bruke @PropertySources kommentar og spesifiser en matrise av @PropertySource. Dette fungerer i alle støttede Java-versjoner, ikke bare i Java 8 eller nyere:

@PropertySources ({@PropertySource ("classpath: foo.properties"), @PropertySource ("classpath: bar.properties")}) offentlig klasse PropertiesWithJavaConfig {// ...}

I begge tilfeller er det verdt å merke seg at i tilfelle kollisjon på et eiendomsnavn, har den siste kildelesingen forrang.

3. Bruke / injisere egenskaper

Injisere en eiendom med @Verdi kommentar er grei:

@Value ("$ {jdbc.url}") privat streng jdbcUrl;

Vi kan også spesifisere en standardverdi for eiendommen:

@Value ("$ {jdbc.url: aDefaultUrl}") privat streng jdbcUrl;

Den nye PropertySourcesPlaceholderConfigurer lagt til våren 3.1 løse $ {...} plassholdere innenfor verdier for bønnedefinisjonsegenskaper og @Verdi kommentarer.

Endelig kan vi få verdien av en eiendom ved hjelp av Miljø API:

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

4. Egenskaper med vårstøvel

Før vi går inn på mer avanserte konfigurasjonsalternativer for eiendommer, la oss bruke litt tid på å se på den nye eiendomsstøtten i Spring Boot.

Generelt sett denne nye støtten innebærer mindre konfigurasjon sammenlignet med standard vår, som selvfølgelig er et av hovedmålene til Boot.

4.1. application.properties: standardegenskapefilen

Boot bruker sin typiske konvensjon over konfigurasjonsmetode til eiendomsfiler. Dette betyr at vi kan ganske enkelt sette en application.properties filen i vår src / main / resources katalogen, og den blir automatisk oppdaget. Vi kan deretter injisere eventuelle belastede egenskaper fra det som normalt.

Så ved å bruke denne standardfilen, trenger vi ikke å registrere en eksplisitt PropertySource eller til og med gi en sti til en eiendomsfil.

Vi kan også konfigurere en annen fil ved kjøretid, hvis vi trenger det, ved hjelp av en miljøegenskap:

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

Fra og med Spring Boot 2.3, Vi kan også spesifisere plasseringen av jokertegn for konfigurasjonsfiler.

For eksempel kan vi stille inn spring.config.location eiendom til config / * /:

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

På denne måten vil Spring Boot se etter konfigurasjonsfiler som samsvarer med config / * / katalogmønster utenfor jar-filen vår. Dette er nyttig når vi har flere kilder til konfigurasjonsegenskaper.

Siden versjon 2.4.0, Spring Boot støtter bruk av fler-dokumentegenskapsfiler, på samme måte som YAML gjør av design:

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

Vær oppmerksom på at for egenskapsfiler er merket med tre streker foran med et kommentartegn (#).

4.2. Miljøspesifikke egenskaper

Hvis vi trenger å målrette mot forskjellige miljøer, er det en innebygd mekanisme for det i Boot.

Vi kan ganske enkelt definere en applikasjonsmiljø.egenskaper filen i src / main / resources katalogen, og angi deretter en vårprofil med samme miljønavn.

For eksempel, hvis vi definerer et "iscenesettende" miljø, betyr det at vi må definere et iscenesettelse profil og deretter application-staging.properties.

Denne env-filen lastes inn og vil ha forrang fremfor standardegenskapefilen. Merk at standardfilen fortsatt vil lastes, det er bare at når det er en eiendomskollisjon, har den miljøspesifikke eiendomsfilen forrang.

4.3. Testspesifikke egenskaper

Vi kan også ha et krav om å bruke forskjellige eiendomsverdier når applikasjonen vår er under test.

Spring Boot håndterer dette for oss ved å se i vår src / test / ressurser katalog under en testkjøring. Igjen vil standardegenskaper fortsatt være injiserbare som normalt, men vil bli overstyrt av disse hvis det er en kollisjon.

4.4. De @TestPropertySource Kommentar

Hvis vi trenger mer detaljert kontroll over testegenskapene, kan vi bruke @TestPropertySource kommentar.

Dette lar oss sette testegenskaper for en spesifikk testkontekst, med forrang over standardegenskapskilder:

@RunWith (SpringRunner.class) @TestPropertySource ("/ foo.properties") offentlig klasse FilePropertyInjectionUnitTest {@Value ("$ {foo}") privat String foo; @Test offentlig ugyldig nårFilePropertyProvided_thenProperlyInjected () {assertThat (foo) .isEqualTo ("bar"); }}

Hvis vi ikke vil bruke en fil, kan vi spesifisere navn og verdier direkte:

@RunWith (SpringRunner.class) @TestPropertySource (egenskaper = {"foo = bar"}) offentlig klasse PropertyInjectionUnitTest {@Value ("$ {foo}") privat streng foo; @Test offentlig ugyldig nårPropertyProvided_thenProperlyInjected () {assertThat (foo) .isEqualTo ("bar"); }}

Vi kan også oppnå en lignende effekt ved å bruke eiendommer argument av @SpringBootTest kommentar:

@RunWith (SpringRunner.class) @SpringBootTest (egenskaper = {"foo = bar"}, klasser = SpringBootPropertiesTestApplication.class) offentlig klasse SpringBootPropertyInjectionIntegrationTest {@Value ("$ {foo}") privat String foo; @Test offentlig ugyldig nårSpringBootPropertyProvided_thenProperlyInjected () {assertThat (foo) .isEqualTo ("bar"); }}

4.5. Hierarkiske egenskaper

Hvis vi har egenskaper som er gruppert sammen, kan vi gjøre bruk av @ConfigurationProperties merknad, som vil kartlegge disse eiendomshierarkiene i Java-objektegrafer.

La oss ta noen egenskaper som brukes til å konfigurere en databaseforbindelse:

database.url = jdbc: postgresql: / localhost: 5432 / forekomst database.username = foo database.password = bar

Så la oss bruke merknaden for å kartlegge dem til et databaseobjekt:

@ConfigurationProperties (prefix = "database") offentlig klasse database {String url; String brukernavn; Strengpassord; // standard getters og setters}

Spring Boot bruker konvensjonen over konfigurasjonsmetoden igjen, og kartlegger automatisk mellom eiendomsnavn og tilhørende felt. Alt vi trenger å levere er eiendomsprefikset.

Hvis du vil grave dypere i konfigurasjonsegenskaper, kan du ta en titt på vår grundige artikkel.

4.6. Alternativ: YAML Files

Spring støtter også YAML-filer.

Alle de samme navnereglene gjelder for testspesifikke, miljøspesifikke og standardegenskapsfiler. Den eneste forskjellen er filtypen og en avhengighet av at SnakeYAML-biblioteket er på klassestien vår.

YAML er spesielt bra for hierarkisk eiendomslagring; følgende eiendomsfil:

database.url = jdbc: postgresql: / localhost: 5432 / forekomst database.username = foo database.password = barhemmelighet: foo

er synonymt med følgende YAML-fil:

database: url: jdbc: postgresql: / localhost: 5432 / instans brukernavn: foo passord: bar hemmelighet: foo

Det er også verdt å nevne at YAML-filer ikke støtter @PropertySource kommentar, så hvis vi trenger å bruke denne kommentaren, vil det begrense oss til å bruke en egenskapsfil.

Et annet bemerkelsesverdig poeng er at Spring Boot i versjon 2.4.0 endret måten egenskaper lastes inn fra YAML-filer med flere dokumenter. Tidligere var rekkefølgen de ble lagt til basert på profilaktiveringsrekkefølgen. Med den nye versjonen følger imidlertid rammeverket de samme ordrereglene som vi tidligere angav for .eiendommer filer; egenskaper som er erklært lavere i filen, vil ganske enkelt overstyre de som er høyere oppe.

I tillegg kan profiler i denne versjonen ikke lenger aktiveres fra profilspesifikke dokumenter, noe som gjør resultatet klarere og mer forutsigbart.

4.7. Importerer ytterligere konfigurasjonsfiler

Før versjon 2.4.0 tillot Spring Boot å inkludere flere konfigurasjonsfiler ved hjelp av spring.config.location og spring.config.additional-location eiendommer, men de hadde visse begrensninger. For eksempel måtte de defineres før du startet applikasjonen (som miljø- eller systemegenskaper, eller ved bruk av kommandolinjeargumenter) slik de ble brukt tidlig i prosessen.

I den nevnte versjonen, vi kan bruke vår.konfig.import eiendom innenfor application.properties eller application.yml fil for enkelt å inkludere flere filer. Denne eiendommen støtter noen interessante funksjoner:

• legge til flere filer eller kataloger
• filene kan lastes inn enten fra klassestien eller fra en ekstern katalog
• som indikerer om oppstartsprosessen skulle mislykkes hvis en fil ikke blir funnet, eller om det er en valgfri fil
• importerer utvidelsesløse filer

La oss se et gyldig eksempel:

spring.config.import = classpath: additional-application.properties, classpath: additional-application [.yml], optional: file: ./ external.properties, classpath: additional-application-properties /

Merk: her har vi formatert denne egenskapen ved hjelp av linjeskift bare for klarhetens skyld.

Våren vil behandle import som et nytt dokument satt inn rett under importdeklarasjonen.

4.8. Egenskaper fra kommandolinjeargumenter

Foruten å bruke filer, kan vi sende egenskaper direkte på kommandolinjen:

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

Vi kan også gjøre dette via systemegenskaper, som er gitt før -krukke kommando i stedet for etter det:

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

4.9. Egenskaper fra miljøvariabler

Spring Boot vil også oppdage miljøvariabler og behandle dem som egenskaper:

eksportnavn = verdi java -jar app.jar 

4.10. Randomisering av eiendomsverdier

Hvis vi ikke vil ha deterministiske eiendomsverdier, kan vi bruke RandomValuePropertySource for å randomisere verdiene til egenskapene:

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

4.11. Ytterligere typer eiendomskilder

Spring Boot støtter en rekke eiendomskilder, og implementerer en gjennomtenkt bestilling for å tillate fornuftig overstyring. Det er verdt å konsultere den offisielle dokumentasjonen, som går lenger enn omfanget av denne artikkelen.

5. Konfigurasjon ved hjelp av rå bønner - PropertySourcesPlaceholderConfigurer

I tillegg til de praktiske metodene for å få eiendommer til våren, kan vi også definere og registrere eiendomskonfigurasjonsbønnen manuelt.

Arbeider med PropertySourcesPlaceholderConfigurer gir oss full kontroll over konfigurasjonen, med ulempen å være mer ordentlig og mesteparten av tiden unødvendig.

La oss se hvordan vi kan definere denne bønnen ved hjelp av Java-konfigurasjon:

@Bean offentlig statisk PropertySourcesPlaceholderConfigurer egenskaper () {PropertySourcesPlaceholderConfigurer pspc = ny PropertySourcesPlaceholderConfigurer (); Ressurs [] resources = new ClassPathResource [] {new ClassPathResource ("foo.properties")}; pspc.setLocations (ressurser); pspc.setIgnoreUnresolvablePlaceholders (true); retur pspc; }

6. Egenskaper i foreldre-barn-sammenhenger

Dette spørsmålet kommer opp igjen og igjen: Hva skjer når vår webapplikasjon har en forelder og en barnesammenheng? Foreldrekonteksten kan ha noen vanlige kjernefunksjonaliteter og bønner, og deretter en (eller flere) barnekontekster, kanskje med servletspesifikke bønner.

I så fall, hva er den beste måten å definere egenskapsfiler og inkludere dem i disse sammenhengene? Og hvordan kan du best hente disse eiendommene fra våren?

Vi gir en enkel oversikt.

Hvis filen er definert i foreldresammenheng:

• @Verdi jobber i Barnesammenheng: JA

• @Verdi jobber i Foreldrekontekst: JA

• environment.getProperty i Barnesammenheng: JA

• environment.getProperty i Foreldrekontekst: JA

Hvis filen er definert i Barnesammenheng:

• @Verdi jobber i Barnesammenheng: JA

• @Verdi jobber i Foreldrekontekst: NEI

• environment.getProperty i Barnesammenheng: JA

• environment.getProperty i Foreldrekontekst: NEI

7. Konklusjon

Denne artikkelen viste flere eksempler på å jobbe med egenskaper og egenskaper filer på våren.

Som alltid er hele koden som støtter artikkelen tilgjengelig på GitHub.