Først application.yml konfigurationsprofil er som følger:
Maven-projektet pom.xml tilføje pakker:
Opret et nyt mappet objekt med følgende kode:
Strengtypen skal kræve en setter for at modtage ejendomsværdier; Kort, samlinger og arrays er ikke nødvendige
Brug @Autowired annotationer til automatisk at indsprøjte, som vist i følgende billede:
esConfig leverer altid null, søgte efter en løsning i lang tid, men fejlede, der vil være en løsning nedenfor.
Lad os oprette en ny controller, koden er som følger:
Injektionen lykkes, og værdierne for yml-konfigurationsfilen opnås normalt som følger:
Årsagerne til, at EsClient ikke kan injiceres med succes, er som følger:
Kald en funktion af denne klasse i konstruktøren, og variablen i @Autowired af denne klasse bruges i denne funktion.
Så jeg tænkte, det kunne gå galt. Fordi @Autowired skal vente på, at klassen er konstrueret, før den kan sættes ud fra eksterne referencer. Derfor skal injektionstiden for @Autowired være længere end konstruktørens eksekveringstid.
Spring Team anbefaler: "Brug altid konstruktørbaseret afhængighedsinjektion i dine bønner. Brug altid assertions for obligatoriske afhængigheder".
Oversættelse:
Spring foreslår: "Etabler altid afhængighedsindsprøjtning med konstruktører i din bønne. brug altid påstande til at tvinge afhængigheder".
Original skrivning:
Modificeret skrift:
PS: Initialiseringsrækkefølgen for Java-variabler er: statiske variabler eller statiske statement-blokke – > instansvariabler eller initialiserings-sætningsblokke – >konstruktionsmetode – >@Autowired
Så hvorfor tilføje den sidste type til medlemvariablen?
Der findes en forklaring på internettet som følger: Omfanget af standardbønnen i forårskonfigurationen er singleton, som altid er der efter opstart. Deklarér bønnens objekt til dynamisk at blive oprettet ved at sætte scope-egenskaben til prototype. Men hvis din service i sig selv er en singleton, udføres injektionen kun én gang.
@Autowired selv er en singleton-tilstand, vil den kun blive udført én gang, når programmet starter, og den vil ikke initialisere en anden gang, selvom den ikke definerer en final, så denne final er meningsløs.
Det kan være for at forhindre, at konstruktøren bliver kørt igen, mens programmet kører;
Eller måske er det nemmere at forstå, plus at final kun initialiserer én gang, når programmet starter.
|
Opslået på 07/01/2019 15.37.14
|
|
|
|
