component-scan / annotation-config / annotation-driven 차이점

component-scan /  annotation-config /  annotation-driven  차이점

최근에 스프링(3.2)으로 개발하게 되면서 가장 어려웠던것은, 스프링 설정인데 버전이 올라가면서 
바뀐분/기존부분등이 서로 어울어져있어서 (특히 검색해서 코드를 짜다보면) 어떤것이 맞는건지, 
어떤것을 해야하는지 선택의 과정에서 힘들게했다.  스타트업회사의 특성상 여러가지일들을 하다보니  
스프링만 주구장창 만지고있을수는 없으니 ,  시간이 지나서 다시보면 또다시 헥깔리고..ㅎㅎ
오늘은  그동안 무턱대고 써온 component-scan / annotation-config / annotation-driven  이것들에 
대해서 알아본다.

---

많은 스프링개발자들이  스프링 IOC 컨테이너 안에서 어노테이션이 어떻게 작동하는지에 대해 혼동을 하고

있는데 스프링 MVC 프레임워크는 효율적으로 빈들을 관리하고 빈을 요구되어지는곳에 주입시키기위해  스프링 컨테이터를 도와주거나  지침을 줄수있는 여러  설정방법들을 제공한다. 

스프링 설정파일에서 보여지는 XML 설정은 다음과 같은것들이 있는데  

• context:component-scan

• mvc:annotation-config

• context:annotation-driven
  

위의 어노테이션의 기능은 유사하며 , 특정 시나리오 상에서 어떻게 반응하는지에 대한 작은 차이점이 있다. 
이 튜토리얼은 언제 그것이 요구되어지는지 각각 요소들에 대해 중요한 포인트를 짚어본다.

1. <context:component-scan/>

이 요소는 스프링 2.5 버전에 소개되어졌으며 , 만약 그 이전 버전의 스프링으로 작업하려면 , 모든 빈들은 수동적으로 XML 파일에 설정되어야 했었다.  자바빈에 대해 어노테이션 지원은 없었다.  이것은 많은 XML 코딩을 초래했으며 ,유지보수에서도 심각한 문제가 있었다. context:component-scan 요소는 XML 파일안의 모든 빈들의 선언을 제거했다. 

아래는 스프링 설정파일에서 선언된 모습이다.

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

위의 선언은 특정 패키지(위에서는 org.controller) 안의 클래스들을 스캔하고 , 빈 인스턴스를 생성한다. 

아래와 같은 정확한 어노테이션이 존재해야지 빈을 생성할수있다. 

• @Component
• @Repository
• @Service
• @Controller
  
  

이것의  장점중 하나는   @Autowired and @Qualifier 어노테이션을 이해한다는것인데 

만약 당신이 <context:component-scan> 를 선언했다면 <context:annotation-config> 를
선언할필요가 없다는것이다.

DefaultAnnotationHandlerMapping는 type레벨에서 @RequestMapping을 처리하고  AnnotationMethodHandlerAdapter는 메서드레벨에서 처리하는데 사용합니다. 이 2가지는 DispatcherServlet을 사용할 경우 디폴트로 사용되지만 다른 핸들러맵핑을 합께 사용하려고 하면 지정하여야 합니다. 

2. <mvc:annotation-driven/>

mvc:annotation-driven 는 스프링 MVC 컴포넌트들을 그것의 디폴트 설정을 가지고  활성화 하기위해 

사용된다. 만약  context:component-scan 을 XML 파일에서 빈을 생성하기위해 사용하면서 mvc:annotation-driven 를  포함시키지 않아도 MVC 어플리케이션은 작동할것이다. 그러나  mvc:annotation-driven 은 특별한

일들을 하는데 이 태그는 당신의 @Controllers 에게 요청을 전파하기위해  요구되는  HandlerMapping 와  HandlerAdapter 를 등록한다.  게다가 , 클래스패스상에 존재하는것에 기반한 아래와 같은 어떤 

디폴트 작업을 적용한다.  

• Using the Spring 3 Type ConversionService as a simpler and more robust alternative to JavaBeans PropertyEditors
• Support for formatting Number fields with @NumberFormat
• Support for formatting Date, Calendar, and Joda Time fields with @DateTimeFormat, if Joda Time is on the classpath
• Support for validating @Controller inputs with @Valid, if a JSR-303 Provider is on the classpath
• Support for reading and writing XML, if JAXB is on the classpath
• Support for reading and writing JSON, if Jackson is on the classpath

질문: 이거  xml 안에 선언안해주면  @Controller 와  @RequestMapping 은 잘 동작하나?  

답변 : 

대중들의 믿음과 대조적으로 이 두개 (component-scan 과 annotation-driven) 의 선언에 는 어떤 

의존성이 없다. context:component-scan 이 포함해주면  mvc:annotation-driven  선언안해

준 @Controller / @RequestMapping 도  요청을 핸들링하는것이나 이슈 없이 잘 동작한다. 

3. <context:annotation-config/>

context:annotation-config 는 어플리케이션 컨텍스트안에 이미 등록된 빈들의 어노테이션을 활성화를 위해 사용된다. (그것들이 XML 으로 설정됬는지 혹은 패키지스캐닝을 통한건지는 중요하지 않다) 

그 의미는 이미 스프링 컨텍스트에 의해 생성되어 저장된  빈들에 대해서  @Autowired and @Qualifier 

어노테이션을 해석할거란 얘기다.

context:component-scan   또한 같은일을 할수있는데, 추가적으로 어플리케이션 컨텍스트에 빈을 등록하기위한 패키지들을 스캔한다. context:annotation-config 은 빈을 등록하기위해 검색할수없다. 

<context:annotation-config /> 태그를 설정하면 아래의 기능을 각각 설정하는 수고를 덜게 해준다. 

- RequiredAnnotationBeanPostProcessor : @Required 어노테이션 처리

- AutowiredAnnotationBeanPostProcessor : @Autowired 어노테이션 처리

   <bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

- CommonAnnotationBeanPostProcessor : @Resource, @PostConstruct, @PreDestroy 어노테이션 처리

- ConfigurationClassPostProcessor : @Configuration 어노테이션 처리

---

component-scan / annotation-config 의 차이

http://stackoverflow.com/questions/7414794/difference-between-contextannotation-config-vs-contextcomponent-scan

---

component-scan /  annotation-driven 의 차이

http://stackoverflow.com/questions/20551217/spring-support-for-controller-given-by-contextcomponent-scan-vs-mvcannot

참고

http://www.javabeat.net/spring-mvc-component-scan-annotations/