Różnica między <kontekstem: annotacja-config> a <kontekstem: skanowanie komponentów>

Uczę się wiosny 3 i wydaje mi się, że nie rozumiem funkcjonalności stojącej za <context:annotation-config>i <context:component-scan>.

Z tego co czytałem wydają się obsługiwać różne adnotacje ( @Required, @Autowiredetc vs @Component, @Repository, @Serviceetc), ale również z tego co czytałem rejestrują te same procesory fasola pocztowe klas.

Mylić mnie jeszcze bardziej, jest annotation-config atrybut na <context:component-scan>.

Czy ktoś może rzucić nieco światła na te tagi? Co jest podobne, co inne, jedno jest zastępowane przez drugie, uzupełniają się nawzajem, czy potrzebuję jednego z nich, obu?

<context:annotation-config> służy do aktywacji adnotacji w komponentach bean już zarejestrowanych w kontekście aplikacji (bez względu na to, czy zostały one zdefiniowane za pomocą XML, czy poprzez skanowanie pakietów).

<context:component-scan>może również robić to, co <context:annotation-config>robi, ale<context:component-scan> także skanuje pakiety, aby znaleźć i zarejestrować komponenty bean w kontekście aplikacji.

Wykorzystam kilka przykładów, aby pokazać różnice / podobieństwa.

Zacznijmy od podstawowej konfiguracji trzech ziaren tego typu A, Bi C, Bi Cwstrzyknięcia do A.

package com.xxx;
public class B {
  public B() {
    System.out.println("creating bean B: " + this);
  }
}

package com.xxx;
public class C {
  public C() {
    System.out.println("creating bean C: " + this);
  }
}

package com.yyy;
import com.xxx.B;
import com.xxx.C;
public class A { 
  private B bbb;
  private C ccc;
  public A() {
    System.out.println("creating bean A: " + this);
  }
  public void setBbb(B bbb) {
    System.out.println("setting A.bbb with " + bbb);
    this.bbb = bbb;
  }
  public void setCcc(C ccc) {
    System.out.println("setting A.ccc with " + ccc);
    this.ccc = ccc; 
  }
}

Dzięki następującej konfiguracji XML:

<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A">
  <property name="bbb" ref="bBean" />
  <property name="ccc" ref="cBean" />
</bean>

Ładowanie kontekstu daje następujące wyniki:

creating bean B: com.xxx.B@c2ff5
creating bean C: com.xxx.C@1e8a1f6
creating bean A: com.yyy.A@1e152c5
setting A.bbb with com.xxx.B@c2ff5
setting A.ccc with com.xxx.C@1e8a1f6

OK, to oczekiwany wynik. Ale to wiosna w „starym stylu”. Teraz mamy adnotacje, więc wykorzystajmy je, aby uprościć XML.

Po pierwsze, pozwala na automatyczne bbbi cccwłaściwości bean w następujący Asposób:

package com.yyy;
import org.springframework.beans.factory.annotation.Autowired;
import com.xxx.B;
import com.xxx.C;
public class A { 
  private B bbb;
  private C ccc;
  public A() {
    System.out.println("creating bean A: " + this);
  }
  @Autowired
  public void setBbb(B bbb) {
    System.out.println("setting A.bbb with " + bbb);
    this.bbb = bbb;
  }
  @Autowired
  public void setCcc(C ccc) {
    System.out.println("setting A.ccc with " + ccc);
    this.ccc = ccc;
  }
}

To pozwala mi usunąć następujące wiersze z pliku XML:

<property name="bbb" ref="bBean" />
<property name="ccc" ref="cBean" />

Mój XML jest teraz uproszczony do tego:

<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A" />

Podczas ładowania kontekstu otrzymuję następujące dane wyjściowe:

creating bean B: com.xxx.B@5e5a50
creating bean C: com.xxx.C@54a328
creating bean A: com.yyy.A@a3d4cf

OK, to źle! Co się stało? Dlaczego moje właściwości nie są tworzone automatycznie?

Cóż, adnotacje są fajną funkcją, ale same w sobie nic nie robią. Po prostu dodają adnotacje. Potrzebujesz narzędzia do przetwarzania, aby znaleźć adnotacje i coś z nimi zrobić.

<context:annotation-config>na pomoc. To aktywuje akcje dla adnotacji, które znajdzie na komponentach bean zdefiniowanych w tym samym kontekście aplikacji, w którym sama jest zdefiniowana.

Jeśli zmienię XML na to:

<context:annotation-config />
<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A" />

po załadowaniu kontekstu aplikacji uzyskuję odpowiedni wynik:

creating bean B: com.xxx.B@15663a2
creating bean C: com.xxx.C@cd5f8b
creating bean A: com.yyy.A@157aa53
setting A.bbb with com.xxx.B@15663a2
setting A.ccc with com.xxx.C@cd5f8b

OK, to miłe, ale usunąłem dwa wiersze z pliku XML i dodałem jeden. To nie jest bardzo duża różnica. Pomysł z adnotacjami polega na tym, że ma on usunąć XML.

Usuńmy więc definicje XML i zastąpmy je adnotacjami:

package com.xxx;
import org.springframework.stereotype.Component;
@Component
public class B {
  public B() {
    System.out.println("creating bean B: " + this);
  }
}

package com.xxx;
import org.springframework.stereotype.Component;
@Component
public class C {
  public C() {
    System.out.println("creating bean C: " + this);
  }
}

package com.yyy;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import com.xxx.B;
import com.xxx.C;
@Component
public class A { 
  private B bbb;
  private C ccc;
  public A() {
    System.out.println("creating bean A: " + this);
  }
  @Autowired
  public void setBbb(B bbb) {
    System.out.println("setting A.bbb with " + bbb);
    this.bbb = bbb;
  }
  @Autowired
  public void setCcc(C ccc) {
    System.out.println("setting A.ccc with " + ccc);
    this.ccc = ccc;
  }
}

Podczas gdy w XML zachowujemy tylko to:

<context:annotation-config />

Ładujemy kontekst, a wynik jest ... Nic. Żadne ziarna nie są tworzone, żadne ziarna nie są automatycznie przetwarzane. Nic!

Jest tak, ponieważ, jak powiedziałem w pierwszym akapicie, <context:annotation-config />jedyne działa na fasolach zarejestrowanych w kontekście aplikacji. Ponieważ usunąłem konfigurację XML dla trzech ziaren, nie ma żadnego komponentu bean i <context:annotation-config />nie ma „celów” do pracy.

Ale to nie będzie problem, w przypadku <context:component-scan>którego można przeskanować pakiet w poszukiwaniu „celów”, nad którymi będzie działać. Zmieńmy zawartość konfiguracji XML na następujący wpis:

<context:component-scan base-package="com.xxx" />

Podczas ładowania kontekstu otrzymuję następujące dane wyjściowe:

creating bean B: com.xxx.B@1be0f0a
creating bean C: com.xxx.C@80d1ff

Hmmmm ... czegoś brakuje. Dlaczego?

Jeśli przyjrzysz się bliżej klasom, klasa Ama pakiet, com.yyyale określiłem go w <context:component-scan>pakiecie do użycia, com.xxxwięc całkowicie pominąłem moją Aklasę i tylko odebrałem Bi Cktórecom.xxx pakiecie.

Aby to naprawić, dodaję również ten inny pakiet:

<context:component-scan base-package="com.xxx,com.yyy" />

a teraz otrzymujemy oczekiwany wynik:

creating bean B: com.xxx.B@cd5f8b
creating bean C: com.xxx.C@15ac3c9
creating bean A: com.yyy.A@ec4a87
setting A.bbb with com.xxx.B@cd5f8b
setting A.ccc with com.xxx.C@15ac3c9

I to wszystko! Teraz nie masz już definicji XML, masz adnotacje.

Jako ostatni przykład, zachowując adnotacjami klas A, Ba Ci dodanie następujących do XML, co otrzymamy po załadowaniu kontekst?

<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />

Nadal otrzymujemy poprawny wynik:

creating bean B: com.xxx.B@157aa53
creating bean C: com.xxx.C@ec4a87
creating bean A: com.yyy.A@1d64c37
setting A.bbb with com.xxx.B@157aa53
setting A.ccc with com.xxx.C@ec4a87

Nawet jeśli fasola dla klasy Anie zostanie uzyskana przez skanowanie, narzędzia przetwarzania są nadal stosowane do <context:component-scan>wszystkich ziaren zarejestrowanych w kontekście aplikacji, nawet dlaA których została ręcznie zarejestrowana w pliku XML.

Ale co, jeśli będziemy mieć następujący kod XML, czy otrzymamy zduplikowane komponenty bean, ponieważ wybraliśmy oba <context:annotation-config />i <context:component-scan>?

<context:annotation-config />
<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />

Nie, bez duplikatów, ponownie otrzymujemy oczekiwany wynik:

creating bean B: com.xxx.B@157aa53
creating bean C: com.xxx.C@ec4a87
creating bean A: com.yyy.A@1d64c37
setting A.bbb with com.xxx.B@157aa53
setting A.ccc with com.xxx.C@ec4a87

Jest tak, ponieważ oba tagi rejestrują te same narzędzia przetwarzania ( <context:annotation-config />można je pominąć, jeśli <context:component-scan>jest określony), ale Spring zadba o ich uruchomienie tylko raz.

Nawet jeśli zarejestrujesz narzędzia do przetwarzania wiele razy, Spring nadal upewni się, że wykonają swoją magię tylko raz; ten XML:

<context:annotation-config />
<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />
<bean id="bla" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla1" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla2" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla3" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />

nadal będzie generować następujący wynik:

creating bean B: com.xxx.B@157aa53
creating bean C: com.xxx.C@ec4a87
creating bean A: com.yyy.A@25d2b2
setting A.bbb with com.xxx.B@157aa53
setting A.ccc with com.xxx.C@ec4a87

OK, chodzi o rapowanie.

Mam nadzieję, że te informacje wraz z odpowiedziami @Tomasz Nurkiewicz i @Sean Patrick Floyd są wszystkim, czego potrzebujesz, aby zrozumieć, jak <context:annotation-config>i jak <context:component-scan>pracować.

Znalazłem to miłe podsumowanie, które adnotacje są zbierane przez które deklaracje. Studiując go, zauważysz, że <context:component-scan/>rozpoznaje on zestaw adnotacji rozpoznawanych przez <context:annotation-config/>, a mianowicie:

• @Component, @Service, @Repository, @Controller,@Endpoint
• @Configuration, @Bean, @Lazy, @Scope, @Order, @Primary, @Profile, @DependsOn, @Import,@ImportResource

Jak widać, <context:component-scan/>logicznie rozszerza się <context:annotation-config/> o funkcje skanowania komponentów CLASSPATH i Java @Configuration.

Wiosna pozwala zrobić dwie rzeczy:

1. Autowired fasoli
2. Automatyczne wykrywanie ziaren

1. Automatyczne okablowanie
Zwykle w applicationContext.xml definiujesz ziarna, a inne ziarna są podłączone za pomocą metod konstruktora lub ustawiacza. Fasole można łączyć za pomocą XML lub adnotacji. W przypadku korzystania z adnotacji należy je aktywować i dodać <context:annotation-config />w pliku applicationContext.xml . Uprości to strukturę tagu z applicationContext.xml , ponieważ nie będziesz musiał ręcznie łączyć bean (konstruktora lub setera). Możesz użyć @Autowireadnotacji, a fasola zostanie połączona według typu.

Krokiem do przodu w zakresie unikania ręcznej konfiguracji XML jest

2. Autodiscovery
Autodiscovery upraszcza XML o krok dalej, w tym sensie, że nawet nie potrzebujesz dodawać <bean>znacznika do applicationContext.xml . Po prostu oznaczysz konkretne ziarna za pomocą jednej z poniższych adnotacji, a Spring automatycznie połączy zaznaczone ziarna i ich zależności do pojemnika Spring. Adnotacje są następujące: @Controller , @Service , @Component , @Repository . Używając <context:component-scan>i wskazując pakiet podstawowy, Spring automatycznie wykryje i podłączy komponenty do pojemnika Spring.

Jako podsumowanie:

• <context:annotation-config />jest używany, aby móc korzystać z adnotacji @Autowired
• <context:component-scan /> służy do określania wyszukiwania określonych ziaren i próby automatycznej instalacji.

<context:annotation-config> aktywuje wiele różnych adnotacji w komponentach bean, niezależnie od tego, czy są one zdefiniowane w XML, czy poprzez skanowanie komponentów.

<context:component-scan> służy do definiowania ziaren bez użycia XML

Aby uzyskać więcej informacji, przeczytaj:

• 3,9 Konfiguracja kontenera oparta na adnotacjach
• 3.10 Skanowanie ścieżki klasy i zarządzane komponenty

Różnica między nimi jest naprawdę prosta!.

<context:annotation-config /> 

Umożliwia korzystanie z adnotacji, które ograniczają się do okablowania właściwości i konstruktorów tylko ziaren !.

Natomiast

<context:component-scan base-package="org.package"/> 

Umożliwia wszystko, co <context:annotation-config />może zrobić, korzystając z dodatkiem stereotypy np .. @Component, @Service, @Repository. Możesz więc połączyć całą fasolę i nie ograniczać się tylko do konstruktorów lub właściwości!

<context:annotation-config>: Skanowanie i aktywowanie adnotacji dla już zarejestrowanych ziaren w wiosennym pliku konfiguracyjnym xml.

<context:component-scan>: Rejestracja fasoli +<context:annotation-config>

@Autowired i @Required są na poziomie właściwości celu, więc fasola powinna zarejestrować się wiosną MKOl przed użyciem tych adnotacji. Aby włączyć te adnotacje, należy zarejestrować odpowiednie komponenty bean lub dołączyć <context:annotation-config />. tzn. <context:annotation-config />działa tylko z zarejestrowaną fasolą.

@Required włącza RequiredAnnotationBeanPostProcessor narzędzie do przetwarzania
@Autowired umożliwia AutowiredAnnotationBeanPostProcessornarzędzie do przetwarzania

Uwaga: sama adnotacja nie ma nic do roboty, potrzebujemy Narzędzia Przetwarzania , które jest pod nią klasą odpowiedzialną za proces podstawowy.

@Repository, @Service i @Controller są @Component i są ukierunkowane na poziom klasy .

<context:component-scan>skanuje paczkę oraz znajduje i rejestruje ziarna, a także obejmuje pracę wykonaną przez <context:annotation-config />.

Migracja XML do adnotacji

The <context:annotation-config>Tag mówi Wiosna skanować kodzie do automatycznego rozwiązywania wymagania zależność klas zawierających @Autowired adnotacji.

Spring 2.5 dodaje także obsługę adnotacji JSR-250, takich jak @Resource, @PostConstruct i @ PreDestroy. Korzystanie z tych adnotacji wymaga również, aby niektóre procesory BeanPostProcesory były zarejestrowane w kontenerze Spring. Jak zawsze można je zarejestrować jako indywidualne definicje komponentu bean, ale można je również domyślnie zarejestrować, włączając<context:annotation-config> znacznik do konfiguracji sprężynowej.

Zaczerpnięte z wiosennej dokumentacji konfiguracji opartej na adnotacjach

Wiosna umożliwia automatyczne wykrywanie „stereotypowych” klas i rejestrowanie odpowiednich definicji BeanDefinition w ApplicationContext.

Według javadoc z org.springframework.stereotype :

Stereotypy to adnotacje oznaczające role typów lub metod w ogólnej architekturze (na poziomie koncepcyjnym, a nie implementacyjnym). Przykład: @Controller @Service @Repository itp. Są one przeznaczone do użycia przez narzędzia i aspekty (tworząc idealny cel dla skrótów punktowych).

Aby automatycznie wykryć takie „stereotypowe” klasy, <context:component-scan> wymagany jest tag.

<context:component-scan>Tag mówi również Wiosna zeskanować kod fasoli iniekcji w ramach pakietu (i wszystkie jego podpakietów) określona.

<context:annotation-config>

Rozwiązuje tylko@Autowired i @Qualiferadnotacje, to wszystko, chodzi o wstrzykiwanie zależności. Istnieją inne adnotacje, które wykonują tę samą pracę, myślę, jak@Inject , ale wszystko w celu rozwiązania DI za pomocą adnotacji.

Pamiętaj, że nawet po zadeklarowaniu <context:annotation-config>elementu musisz zadeklarować swoją klasę jak Fasola, pamiętaj, że mamy trzy dostępne opcje

• XML: <bean>
• @ Adnotacje: @Component, @Service, @Repository, @Controller
• JavaConfig: @Configuration, @Bean

Teraz z

<context:component-scan>

Robi dwie rzeczy:

• Skanuje wszystkie klasy opatrzone adnotacjami @Component, @Service, @Repository, @Controller i @Configuration i tworzy komponent Bean
• Robi to samo, co <context:annotation-config>robi.

Dlatego, jeśli zadeklarujesz <context:component-scan>, nie jest już więcej konieczne<context:annotation-config> .

To wszystko

Typowym scenariuszem było na przykład zadeklarowanie tylko fasoli za pomocą XML i rozwiązanie DI na przykład poprzez adnotacje

<bean id="serviceBeanA" class="com.something.CarServiceImpl" />
<bean id="serviceBeanB" class="com.something.PersonServiceImpl" />
<bean id="repositoryBeanA" class="com.something.CarRepository" />
<bean id="repositoryBeanB" class="com.something.PersonRepository" />

Mamy tylko zadeklarowane fasolę, nic na ten temat <constructor-arg>i <property>DI jest skonfigurowany w swoich klasach przez @Autowired. Oznacza to, że Usługi używają @Autowired dla swoich komponentów Repozytoriów, a Repozytoria używają @Autowired dla komponentów JdbcTemplate, DataSource itp.

<context:component-scan /> implicitly enables <context:annotation-config/>

spróbuj <context:component-scan base-package="..." annotation-config="false"/>w konfiguracji @Service, @Repository, @Component działa dobrze, ale @ Autowired, @ Resource i @Inject nie działa.

Oznacza to, że AutowiredAnnotationBeanPostProcessor nie zostanie włączony, a kontener Spring nie przetworzy adnotacji Autowired.

<context:annotation-config/> <!-- is used to activate the annotation for beans -->
<context:component-scan base-package="x.y.MyClass" /> <!-- is for the Spring IOC container to look for the beans in the base package. -->

Inną ważną kwestią, na którą należy zwrócić uwagę, jest to, że context:component-scandomyślnie wywołuje funkcję context:annotation-configaktywacji adnotacji na fasoli. Dobrze, jeśli nie chcesz context:component-scan, aby domyślnie włączyć adnotacje dla ciebie, możesz iść na ustawienie elementu adnotacji-Config context:component-scandofalse .

Podsumowując:

<context:annotation-config/> <!-- activates the annotations --> 
<context:component-scan base-package="x.y.MyClass" /> <!-- activates the annotations + register the beans by looking inside the base-package -->

<context:component-scan base-package="package name" />:

Służy to do poinformowania kontenera, że ​​w moim pakiecie są klasy fasoli, które skanują te klasy fasoli. Aby przeskanować klasy fasoli według kontenera na górze fasoli, musimy napisać jedną z adnotacji typu stereo, jak poniżej.

@Component, @Service, @Repository,@Controller

<context:annotation-config />:

Jeśli nie chcemy jawnie zapisywać tagu bean w XML, to skąd kontener wie, czy w beanie jest automatyczne okablowanie. Jest to możliwe przy użyciu @Autowiredadnotacji. musimy poinformować kontener, że w mojej fasoli jest automatyczne okablowanie context:annotation-config.

Znacznik <context:component-scan/>niestandardowy rejestruje ten sam zestaw definicji komponentu bean, który jest wykonywany, poza jego główną odpowiedzialnością za skanowanie pakietów java i rejestrowanie definicji komponentu bean ze ścieżki klasy.

Jeśli z jakiegoś powodu należy unikać tej rejestracji domyślnych definicji komponentu bean, można to zrobić poprzez określenie dodatkowego atrybutu „adnotation-config” w skanie składników:

<context:component-scan basePackages="" annotation-config="false"/>

Odniesienie: http://www.java-allandsundry.com/2012/12/contextcomponent-scan-contextannotation.html

<context:annotation-config>:

Mówi to Springowi, że użyję fasolki z adnotacjami jako fasoli wiosennej, a te zostaną połączone za pomocą @Autowiredadnotacji, zamiast deklarować w wiosennym pliku konfiguracyjnym xml.

<context:component-scan base-package="com.test..."> :

To mówi kontenerowi Spring, gdzie rozpocząć wyszukiwanie fasoli z adnotacjami. Tutaj wiosna przeszuka wszystkie paczki podrzędne pakietu podstawowego.

więcej informacji można znaleźć w wiosennym pliku schematu kontekstowego. poniżej znajduje się w Spring-context-4.3.xsd

<conxtext:annotation-config />

Activates various annotations to be detected in bean classes: Spring's @Required and
@Autowired, as well as JSR 250's @PostConstruct, @PreDestroy and @Resource (if available),
JAX-WS's @WebServiceRef (if available), EJB 3's @EJB (if available), and JPA's
@PersistenceContext and @PersistenceUnit (if available). Alternatively, you may
choose to activate the individual BeanPostProcessors for those annotations.

Note: This tag does not activate processing of Spring's @Transactional or EJB 3's
@TransactionAttribute annotation. Consider the use of the <tx:annotation-driven>
tag for that purpose.

<context:component-scan>

Scans the classpath for annotated components that will be auto-registered as
Spring beans. By default, the Spring-provided @Component, @Repository, @Service, @Controller, @RestController, @ControllerAdvice, and @Configuration stereotypes    will be detected.

Note: This tag implies the effects of the 'annotation-config' tag, activating @Required,
@Autowired, @PostConstruct, @PreDestroy, @Resource, @PersistenceContext and @PersistenceUnit
annotations in the component classes, which is usually desired for autodetected components
(without external configuration). Turn off the 'annotation-config' attribute to deactivate
this default behavior, for example in order to use custom BeanPostProcessor definitions
for handling those annotations.

Note: You may use placeholders in package paths, but only resolved against system
properties (analogous to resource paths). A component scan results in new bean definitions
being registered; Spring's PropertySourcesPlaceholderConfigurer will apply to those bean
definitions just like to regular bean definitions, but it won't apply to the component
scan settings themselves.

Jako uzupełnienie możesz użyć @ComponentScando użycia<context:component-scan> w sposób adnotacji.

Jest to również opisane w spring.io

Konfiguruje dyrektywy skanowania komponentów do użytku z klasami @Configuration. Zapewnia obsługę równoległą z elementem Spring XML.

Należy zauważyć, że jeśli używasz Spring Boot, @Configuration i @ComponentScan można implikować za pomocą adnotacji @SpringBootApplication.