Våren @ConditionalOnProperty kommentar

1. Oversikt

I denne korte veiledningen skal vi belyse det viktigste formålet med @ConditionalOnProperty kommentar.

Først begynner vi med litt bakgrunn om hva @ConditionalOnProperty er. Deretter vil vi se på noen praktiske eksempler for å forstå hvordan det fungerer og hvilke funksjoner det gir.

2. Formålet med @ConditionalOnProperty

Når du utvikler vårbaserte applikasjoner, Det kan hende at vi må lage noen bønner betinget av tilstedeværelsen og verdien av en konfigurasjonsegenskap.

For eksempel kan det være lurt å registrere en Datakilde bønne for å peke på en produksjon eller en testdatabase, avhengig av om vi setter en eiendomsverdi til "prod" eller "test".

Heldigvis er det ikke så vanskelig å oppnå det ved første øyekast. Vårrammen gir @ConditionalOnProperty kommentar nettopp for dette formålet.

Kort sagt, den @ConditionalOnProperty muliggjør bare bønneregistrering hvis en miljøegenskap er tilstede og har en spesifikk verdi. Som standard må den spesifiserte egenskapen være definert og ikke være lik falsk.

Nå som vi er kjent med formålet med @ConditionalOnProperty kommentar, la oss grave dypere for å se hvordan det fungerer.

3. Den @ConditionalOnProperty Kommentar i praksis

For å eksemplifisere bruken av @ConditionalOnProperty, Vi utvikler et grunnleggende varslingssystem. For å holde det enkelt for øyeblikket, la oss anta at vi vil sende e-postvarsler.

Først må vi lage en enkel tjeneste for å sende en varslingsmelding. Tenk for eksempel på Varsling Avsender grensesnitt:

offentlig grensesnitt NotificationSender {String send (Strengmelding); }

La oss deretter gi en implementering av Varsling Avsender grensesnitt for å sende e-postene våre:

offentlig klasse EmailNotification implementerer NotificationSender {@Override public String send (strengmelding) {return "E-postvarsling:" + melding; }}

La oss nå se hvordan vi kan bruke @ConditionalOnProperty kommentar. La oss konfigurere Varsling Avsender bønne på en slik måte at den bare lastes hvis eiendommen varsling.tjeneste er definert:

@Bean (name = "emailNotification") @ConditionalOnProperty (prefix = "notification", name = "service") public NotificationSender notificationSender () {return new EmailNotification (); }

Som vi kan se, er prefiks og Navn attributter brukes til å betegne konfigurasjonsegenskapen som skal kontrolleres.

Til slutt må vi legge til den siste manglende biten i puslespillet. La oss definere vår egendefinerte eiendom i application.properties fil:

notification.service = e-post

4. Avansert konfigurasjon

Som vi allerede har lært, er @ConditionalOnProperty kommentar lar oss registrere bønner betinget avhengig av tilstedeværelsen av en konfigurasjonsegenskap.

Vi kan imidlertid gjøre mer enn bare det med denne kommentaren. Så, la oss utforske!

La oss anta at vi vil legge til en annen varslingstjeneste - for eksempel en tjeneste som lar oss sende SMS-varsler.

For å gjøre det, må vi lage en annen Varsling Avsender gjennomføring:

offentlig klasse SmsNotification implementerer NotificationSender {@Override public String send (String message) {return "SMS Notification:" + message; }}

Siden vi har to implementeringer, la oss se hvordan vi kan bruke @ConditionalOnProperty å laste inn høyre Varsling Avsender bønne betinget.

For dette formålet gir kommentaren å ha verdi Egenskap. Ganske interessant, dendefinerer verdien som en eiendom må ha for at en bestemt bønne skal legges til vårbeholderen.

La oss nå spesifisere under hvilken tilstand vi vil registrere SmsVarsling implementering i sammenheng:

@Bean (name = "smsNotification") @ConditionalOnProperty (prefix = "notification", name = "service", havingValue = "sms") public NotificationSender notificationSender2 () {return new SmsNotification (); }

Ved hjelp av å ha verdi attributt, gjorde vi det klart at vi vil laste SmsVarsling bare når varsling.tjeneste er satt til tekstmelding.

Det er verdt å nevne det @ConditionalOnProperty har en annen attributt kalt matchIfMissing. Dette attributtet spesifiserer om betingelsen skal samsvare i tilfelle eiendommen ikke er tilgjengelig.

La oss nå sette sammen alle delene og skrive en enkel testtilfelle for å bekrefte at alt fungerer som forventet:

@Test offentlig ugyldig nårValueSetToEmail_thenCreateEmailNotification () {this.contextRunner.withPropertyValues ​​("notification.service = email") .withUserConfiguration (NotificationConfig.class) .run (kontekst -> {assertThat (kontekst) .hasBean (") = context.getBean (EmailNotification.class); assertThat (notificationSender.send ("Hello From Baeldung!")). isEqualTo ("Email Notification: Hello From Baeldung!"); assertThat (context) .doesNotHaveBean ("smsNotification"); }); }

5. Konklusjon

I denne korte opplæringen fremhevet vi formålet med å bruke @ConditionalOnProperty kommentar. Deretter viste vi gjennom et praktisk eksempel hvordan vi kan bruke den til å laste vårbønner betinget.

Som alltid er hele kildekoden til denne opplæringen tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found