streamalism.org

1. Oversigt

I denne hurtige vejledning forklarer vi forårets Utilfredseafhængighedsundtagelse, hvad der forårsager det, og hvordan man undgår det.

2. Årsag til Utilfredseafhængighedsundtagelse

Utilfredseafhængighedsundtagelse bliver kastet når, som navnet antyder, en afhængighed af bønner eller ejendom ikke er tilfreds.

Dette kan ske, når Spring-applikation forsøger at binde en bønne og ikke kan løse en af ​​de obligatoriske afhængigheder.

3. Eksempel på anvendelse

Antag, at vi har en serviceklasse PurchaseDeptService, som afhænger af Lageropbevaring:

@Service offentlig klasse PurchaseDeptService {public PurchaseDeptService (InventoryRepository repository) {this.repository = repository; }}

offentlig grænseflade InventoryRepository {} 

@Repository public class ShoeRepository implementerer InventoryRepository {}

@SpringBootApplication public class SpringDependenciesExampleApplication {public static void main (String [] args) {SpringApplication.run (SpringDependenciesExampleApplication.class, args); }} 

For nu antager vi, at alle disse klasser er placeret i den samme pakke med navnet com.baeldung.dependency.exception.app.

Når vi kører denne Spring Boot-applikation, fungerer alt fint. Lad os se, hvilken slags problemer vi kan løbe ind i, hvis vi springer et konfigurationstrin over.

4. Manglende komponentkommentar

Lad os nu fjerne @Repository kommentar fra vores Skoopbevaring klasse:

offentlig klasse ShoeRepository implementerer InventoryRepository {}

Når vi starter vores ansøgning igen, ser vi følgende fejlmeddelelse: UnsatisfiedDependencyException: Fejl ved oprettelse af bønne med navnet 'purchaseDeptService': Utilfreds afhængighed udtrykt gennem konstruktorparameter 0

Foråret blev ikke bedt om at binde en Skoopbevaring bønne og tilføj den til applikationskonteksten, kunne derfor ikke injicere den og kastede undtagelsen.

Tilføjelse af @Repository kommentar tilbage på Skoopbevaring løser problemet.

5. Pakke ikke scannet

Lad os nu sætte vores Skoopbevaring (sammen med InventoryRepository) i en separat pakke med navnet com.baeldung.dependency.exception.repository.

Endnu en gang, når vi kører vores app, kaster den Utilfredseafhængighedsundtagelse . For at løse dette kan vi konfigurere pakkescanningen på den overordnede pakke og sørge for, at alle relevante klasser er inkluderet:

@SpringBootApplication @ComponentScan (basePackages = {"com.baeldung.dependency.exception"}) offentlig klasse SpringDependenciesExampleApplication {public static void main (String [] args) {SpringApplication.run (SpringDependenciesExampleApplication.class, args); }} 

6. Ikke-unik afhængighedsopløsning

Antag, at vi tilføjer en anden InventoryRepository implementering - DressRepository:

@Repository offentlig klasse DressRepository implementerer InventoryRepository {} 

Når vi kører vores app, kaster den igen Utilfredseafhængighedsundtagelse.

Denne gang er situationen imidlertid en anden. Efterhånden som det sker, afhængighed kan ikke løses, når der er mere end en bønne, der tilfredsstiller den.

For at løse dette kan vi måske tilføje @Kvalifikator at skelne mellem opbevaringsstederne:

@Qualifier ("kjoler") @Repository offentlig klasse DressRepository implementerer InventoryRepository {} 

@Qualifier ("sko") @Repository offentlig klasse ShoeRepository implementerer InventoryRepository {}

Vi bliver også nødt til at tilføje en kvalifikation til PurchaseDeptService konstruktørafhængighed:

offentlig PurchaseDeptService (@Qualifier ("kjoler") InventoryRepository repository) {this.repository = repository; }

Dette vil gøre DressRepository den eneste mulige løsning, og Spring vil injicere den i PurchaseDeptService.

7. Konklusion

I denne artikel har vi set flere mest almindelige tilfælde af stød Utilfredseafhængighedsundtagelse. Vi har også lært, hvordan vi løser disse problemer.

Det kan også være en god idé at se på den mere generelle vejledning om Spring BeanCreationException.

Koden, der præsenteres her, kan findes på GitHub.