2014-12-27 30 views
5

Mam problem z uzyskaniem konfiguracji Spring, która zostanie zastosowana w pożądanej kolejności przy Spring Boot w wielomodułowym projekcie Maven.Spring Boot AutoConfiguration Order

Mam modułów A i B, które są napisane przeze mnie i uzależnienia od modułu osoby trzeciej, że nie mam kontroli nad w module C (zależności są w następujący sposób: zależy C, B zależy)

W module AI klasy oznaczone są @Configuration, a także @AutoConfigureBefore(ClassFromModuleD.class). Moduł BI już inna klasa opatrzone @Configuration a także @AutoConfigureBefore(ClassFromModuleA.class)

miałem nadzieję, że będzie to skutkować w definicjach fasoli w moim modułem B są skonfigurowane najpierw, a następnie fasoli w moim module Klasa konfiguracja wreszcie te w C

Próbowałem również dodać plik META-INF/spring.factories do obu modułów A i B, który deklaruje pojedynczy plik konfiguracyjny obecny w jego własnym module. Na przykład. o moduł A

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.exmaple.moduleAConfiguration

oraz moduł B:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.exmaple.moduleBConfiguration

nie widzę żądaną kolejność konfiguracji, w rzeczywistości wydaje się być dokładnie odwrotnie do tego, co chcę . Użyłem instrukcji rejestrowania i debuggera, aby przejść i wygląda na to, że konfiguracja z modułu C jest stosowana najpierw, a następnie A w końcu B.

Czy ktoś mógłby wskazać, co mogłem pominąć lub czy jest inny sposób Zrób to? bardzo dziękuję z góry.

+0

można pokazać swoją główną klasę konfiguracji? Co rozumiesz przez "skonfigurowany" (skąd wiesz, że jedna rzecz pojawia się przed innym w e-mailu)? –

+0

Główna klasa konfiguracja wygląda następująco: '@EnableReactor @SpringBootApplication public class SpringConfiguration { }' wierzę, że kolejność nie jest to, co pragnę bo umieściliśmy punkty przerwania w różnych metod i definicji fasoli nie są trafieni w kolejności, na którą liczyłem. Problem polega na tym, że komponent bean w module C próbuje wyszukać komponent bean w kontekście, którego jeszcze nie ma, ponieważ jest skonfigurowany przez moduły A i B, które nie zostały jeszcze automatycznie skonfigurowane ... Jeśli przejdę przez uruchamianie kodu dla moduł C, a następnie jakiś czas później komponenty są konfigurowane (zbyt późno)! –

+0

Adnotacje 'AutoconfigureBefore/After' mają zastosowanie tylko do kolejności importowania klas do fabryki fasoli. Nie mówią nic o kolejności tworzenia fasoli, więc punkty przerwania nie pomagają w zrozumieniu problemu. Jeśli nie można utworzyć komponentu bean, musi on zawierać błąd i ślad stosu, więc może to pomogłoby w opublikowaniu? –

Odpowiedz

0

Wiosenna konfiguracja automatyczna służy do zapewnienia podstawowej konfiguracji, jeśli pewne klasy znajdują się w ścieżce klas.

Używane np. aby zapewnić podstawową konfigurację Jpa, jeśli Hibernacja znajduje się w ścieżce klas.

Jeśli chcesz skonfigurować kolejność, w której ziarna są instancję wiosny można użyć

@DependsOn("A") 
public class B{ 
...  
} 

To stworzyłoby fasoli „A”, niż „B”.

Jednak zamówienie może nie być możliwe. Napisałeś:

A zależy na C, B zależy od

Jeśli 'zależy' oznacza: a potrzebuje C, aby być instancja, ziarna muszą być tworzone w następującej kolejności:

  1. C - C, ponieważ zależy od niczego
  2. A - ponieważ zależy C, który jest już utworzony.
  3. B - ponieważ B zależy od A, który jest już utworzony.

Spring automatycznie wykrywa zależności, analizując klasy komponentów bean.

Jeśli A ma właściwość autowired lub argument cosntructor typu C, wiosna „wie”, że musi instancję C przed A.

W większości przypadków to działa dobrze.

W niektórych przypadkach wiosna nie może "odgadnąć" zależności i tworzy ziarna w niechcianej kolejności. Niż możesz "poinformować" wiosnę przez adnotację @DependsOn na temat zależności. Spring spróbuje odpowiednio zmienić kolejność.

W przypadku, gdy jesteś Zależności opisane nie są widoczne na wiosnę, a zależności nie są potrzebne do tworzenia ziarna, można spróbować zmienić kolejność z @DependsOn:

A zależy na C, B zależy od

można osiągnąć z

@DependsOn("C") 
public class A{ 
    ...  
} 

@DependsOn("A") 
public class B{ 
    ...  
} 

// C comes from another module 
// and no need to annotate