streamalism.org

1. Oversikt

De viktigste Spring Boot-utviklerne gir forretter for de fleste av de populære open source-prosjektene, men vi er ikke begrenset til disse.

Vi kan også skrive våre egne forretter. Hvis vi har et internt bibliotek for bruk i organisasjonen vår, vil det være en god praksis å også skrive en startpakke for det hvis det skal brukes i Spring Boot-sammenheng.

Disse forrettene gjør det mulig for utviklere å unngå langvarig konfigurasjon og raskt starte utviklingen. Men med mange ting som skjer i bakgrunnen, blir det noen ganger vanskelig å forstå hvordan en kommentar eller bare inkluderer en avhengighet i pom.xml muliggjør så mange funksjoner.

I denne artikkelen vil vi avmystifisere Spring Boot-magien for å se hva som skjer bak kulissene. Deretter vil vi bruke disse konseptene til å lage en startpakke for vårt eget tilpassede bibliotek.

2. Avmystifisere Spring Boots autokonfigurasjon

2.1. Automatiske konfigurasjonsklasser

Når Spring Boot starter, ser det etter en fil som heter våren. fabrikker i klassestien. Denne filen ligger i META-INF katalog. La oss se på et utdrag av denne filen fra spring-boot-autoconfigure-prosjektet:

# Automatisk konfigurering av org.springframework.boot.autoconfigure.EnableAutoConfiguration = \ org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration, \ org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration, \ org.springframework. MongoAutoConfiguration, \ org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

Denne filen tilordner et navn til forskjellige konfigurasjonsklasser som Spring Boot vil prøve å kjøre. Så i henhold til dette utdraget vil Spring Boot prøve å kjøre alle konfigurasjonsklassene for RabbitMQ, Cassandra, MongoDB og Hibernate.

Hvorvidt disse klassene faktisk vil kjøre eller ikke, vil avhenge av tilstedeværelsen av avhengige klasser på klassestien. For eksempel, hvis klassene for MongoDB finnes på klassestien, MongoAutoConfiguration vil kjøre og alle mongo-relaterte bønner vil bli initialisert.

Denne betingede initialiseringen er aktivert av @ConditionalOnClass kommentar. La oss se på kodebiten fra MongoAutoConfiguration klasse for å se bruken:

@Configuration @ConditionalOnClass (MongoClient.class) @EnableConfigurationProperties (MongoProperties.class) @ConditionalOnMissingBean (type = "org.springframework.data.mongodb.MongoDbFactory") offentlig klasse MongoAutoConfiguration {// konfigurasjonskode}

Nå hvordan - hvis den MongoClient er tilgjengelig i klassestien - denne konfigurasjonsklassen vil kjøre fylle vårbønnefabrikken med en MongoClient initialisert med standard konfigurasjonsinnstillinger.

2.2. Egendefinerte egenskaper fra application.properties Fil

Spring Boot initialiserer bønnene ved hjelp av noen forhåndskonfigurerte standardinnstillinger. For å overstyre disse standardene, erklærer vi dem generelt i application.properties fil med noe spesifikt navn. Disse egenskapene blir automatisk hentet av Spring Boot-beholderen.

La oss se hvordan det fungerer.

I kodebiten for MongoAutoConfiguration, @EnableConfigurationProperties kommentar erklæres med MongoProperties klasse som fungerer som beholderen for egendefinerte egenskaper:

@ConfigurationProperties (prefix = "spring.data.mongodb") offentlig klasse MongoProperties {private String vert; // andre felt med standard getters og setters}

Prefikset pluss feltnavnet gjør navnene på egenskapene i application.properties fil. Så, for å sette vert for MongoDB trenger vi bare å skrive følgende i eiendomsfilen:

spring.data.mongodb.host = localhost

Tilsvarende kan verdier for andre felt i klassen angis ved hjelp av eiendomsfilen.

3. Lage en tilpasset startpakke

Basert på konseptene i seksjon 2, for å lage en tilpasset startpakke, må vi skrive følgende komponenter:

1. En automatisk konfigurering av klassen for biblioteket vårt sammen med en egenskapsklasse for tilpasset konfigurasjon.
2. En startpakke pom for å få inn avhengighetene til biblioteket og autokonfigurasjonsprosjektet.

For demonstrasjon har vi laget et enkelt hilsenbibliotek som tar inn en hilsenmelding for forskjellige tider på dagen som konfigurasjonsparametere og sender hilsenmeldingen. Vi vil også lage et eksempel på Spring Boot-applikasjon for å demonstrere bruken av autokonfigurasjons- og startmodulene.

3.1. Autokonfigurasjonsmodulen

Vi vil kalle modulen for automatisk konfigurering greeter-spring-boot-autoconfigure. Denne modulen vil ha to hovedklasser, dvs. GreeterEiendommer som vil muliggjøre innstilling av egendefinerte egenskaper gjennom application.properties fil og GreeterAutoConfiguartion som vil lage bønnene til hilsen bibliotek.

La oss se på koden for begge klassene:

@ConfigurationProperties (prefix = "baeldung.greeter") offentlig klasse GreeterProperties {private String userName; privat String morningMessage; privat streng ettermiddagMelding; privat String kveldMelding; private String nightMessage; // standard getters og setters}

@Configuration @ConditionalOnClass (Greeter.class) @EnableConfigurationProperties (GreeterProperties.class) offentlig klasse GreeterAutoConfiguration {@Autowired private GreeterProperties greeterProperties; @Bean @ConditionalOnMissingBean offentlig GreetingConfig greeterConfig () {String brukernavn = greeterProperties.getUserName () == null? System.getProperty ("user.name"): greeterProperties.getUserName (); // .. GreetingConfig greetingConfig = ny GreetingConfig (); greetingConfig.put (USER_NAME, brukernavn); // ... return greetingConfig; } @Bean @ConditionalOnMissingBean public Greeter greeter (GreetingConfig greetingConfig) {return new Greeter (greetingConfig); }}

Vi må også legge til en våren. fabrikker filen i src / main / resources / META-INF katalog med følgende innhold:

org.springframework.boot.autoconfigure.EnableAutoConfiguration = \ com.baeldung.greeter.autoconfigure.GreeterAutoConfiguration

Ved oppstart av programmet, GreeterAutoConfiguration klasse vil kjøre hvis klassen Greeter er til stede i klassestien. Hvis den kjøres vellykket, vil den fylle ut vårkontekstkonteksten med GreeterConfig og Greeter bønner ved å lese egenskapene via GreeterEiendommer klasse.

De @ConditionalOnMissingBean merknader vil sikre at disse bønnene bare blir opprettet hvis de ikke allerede eksisterer. Dette gjør det mulig for utviklere å overstyre de automatisk konfigurerte bønnene ved å definere sine egne i en av @Konfigurasjon klasser.

3.2. Å skape pom.xml

La oss nå lage forretten pom som vil bringe inn avhengighetene for den automatiske konfigurasjonsmodulen og greeter-biblioteket.

I henhold til navnekonvensjonen, bør alle forretter som ikke administreres av kjernen i Spring Boot-teamet, starte med biblioteksnavnet etterfulgt av suffikset -spring-boot-starter. Så vi vil kalle forretten vår som greeter-spring-boot-starter:

 4.0.0 com.baeldung greeter-spring-boot-starter 0.0.1-SNAPSHOT UTF-8 0.0.1-SNAPSHOT 2.2.6.RELEASE org.springframework.boot spring-boot-starter $ {spring-boot.version} com .baeldung greeter-spring-boot-autoconfigure $ {project.version} com.baeldung greeter $ {greeter.version} 

3.3. Bruke starteren

La oss lage greeter-spring-boot-sample-app som vil bruke starteren. I pom.xml vi må legge det til som en avhengighet:

 com.baeldung greeter-spring-boot-starter $ {greeter-starter.version} 

Spring Boot vil automatisk konfigurere alt, og vi vil ha en Greeter bønne klar til å injiseres og brukes.

La oss også endre noen av standardverdiene til GreeterEiendommer ved å definere dem i application.properties fil med baeldung.greeter prefiks:

baeldung.greeter.userName = Baeldung baeldung.greeter.afternoonMessage = Woha \ ettermiddag

Til slutt, la oss bruke Greeter bønne i søknaden vår:

@SpringBootApplication offentlig klasse GreeterSampleApplication implementerer CommandLineRunner {@Autowired private Greeter greeter; public static void main (String [] args) {SpringApplication.run (GreeterSampleApplication.class, args); } @Override public void run (String ... args) kaster unntak {Strengmelding = greeter.greet (); System.out.println (melding); }}

4. Konklusjon

I denne raske opplæringen fokuserte vi på å rulle ut en tilpasset Spring Boot-startpakke, og på hvordan disse forrettene, sammen med autokonfigureringsmekanismen - fungerer i bakgrunnen for å eliminere mye manuell konfigurasjon.

Den komplette kildekoden for alle modulene vi opprettet i denne artikkelen finner du på GitHub.