For det første application.yml konfigurasjonsprofilen er som følger:
Maven-prosjektet pom.xml legge til pakker:
Lag et nytt kartlagt objekt med følgende kode:
Strengtypen må trenge en setter for å motta egenskapsverdier; Kart, samlinger og arrays er ikke påkrevd
Bruk @Autowired annotasjoner for automatisk å injisere, som vist i følgende bilde:
esConfig gir alltid null, har lett etter en løsning lenge, men feilet, det vil finnes en løsning nedenfor.
La oss lage en ny kontroller, koden er som følger:
Injeksjonen er vellykket, og verdiene til yml-konfigurasjonsfilen oppnås normalt, som følger:
Årsakene til at EsClient ikke kan injiseres med suksess er som følger:
Kall en funksjon av denne klassen i konstruktøren, og variabelen til @Autowired i denne klassen brukes i denne funksjonen.
Så jeg trodde det kunne gå galt. Fordi @Autowired må vente på at klassen er konstruert før den kan settes fra eksterne referanser. Derfor må injeksjonstiden til @Autowired være senere enn utførelsestiden til konstruktøren.
Spring Team anbefaler «Bruk alltid konstruktørbasert avhengighetsinjeksjon i bønnene dine. Bruk alltid assertions for obligatoriske avhengigheter".
Oversettelse:
Spring foreslår: «Etabler alltid avhengighetsinjeksjon med konstruktører i bønnen din. bruk alltid påstander for å tvinge frem avhengigheter".
Original manus:
Modifisert skriving:
PS: Initialiseringsrekkefølgen for Java-variabler er: statiske variabler eller statiske setningsblokker – > instansvariabler eller initialiseringsblokker – >konstruksjonsmetode – >@Autowired
Så hvorfor legge til den siste typen i medlemsvariabelen?
Det finnes en forklaring på Internett som følger: Omfanget av standardbønnen i vårkonfigurasjonen er singleton, som alltid er der etter oppstart. Erklære bønnens objekt som dynamisk opprettet ved å sette scope-egenskapen til prototype. Men hvis tjenesten din i seg selv er en singleton, utføres injeksjonen bare én gang.
@Autowired selv er en singleton-modus, vil den bare bli kjørt én gang når programmet starter, og den vil ikke initialisere en andre gang selv om den ikke definerer en final, så denne finalen er meningsløs.
Det kan være for å forhindre at konstruktøren kjøres igjen mens programmet kjører;
Eller kanskje det er lettere å forstå, pluss at final bare initialiseres én gang når programmet starter.
|
Publisert på 07.01.2019 15:37:14
|
|
|
|
