스프링 기본 - 섹션6. 컴포넌트 스캔

 

@Autowired가 뭔지, 기존에 수동으로 만들었던 AppConfig를 어떻게 자동화 하는지 알아보는 내용이다.

 

이렇게 수동으로 등록한 것과

이렇게 자동으로 등록한 것은 같은 역할을 한다.

이게 뭐냐면 AutoAppConfig는 똑같이 @Configuration이지만 @ComponentScan을 통해 AutoAppConfig가 들어있는 패키지 이하(따로 설정 가능)를 모두 스캔해서 annotation @Component가 붙은 클래스를 컨테이너에 등록한다. 다만 이렇게 하면 수동으로 했을 때 DI를 지정해줬지만 AutoAppConfig안엔 아무것도 없으므로 해당 구체화 인스턴스 생성자에 @Autowired로 어떤걸 주입하는지 알려준다.

스캔 범위 설정은 속도를 높이기 위해 가끔 필요한 듯 하다.

 

그럼 의존관계가 필요할 때 수동으로 했을 땐 new로 직접 지정해주고 @AppConfig가 싱글톤으로 알아서 해주고 하는 과정이 있었지만 자동으로 하면 컨테이너에 등록한 것을 그대로 등록해서 사용한다.

 

위 로그를 잘 보면 스캔한 것과 싱글톤 빈으로 등록되었다고 나와있음.

 

이 @Component들 중 특별한 것들 몇개를 보자. 이것들도 @Component 하위 클래스라서 @Component scan 대상에 포함된다(사실 java엔 annotation에 상하 관계는 없지만 스프링이 자체적으로 모방해서 만들었다고 한다.)

@Controller: 스프링 MVC 컨트롤러 인식

@Repository: 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.

@Configuration: 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.

@Service: 사실 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 로직이 여기에 있겠구나 하고 비즈니스 계측을 인식하는데 도움이 된다.

 

그 외에 ComponentScan에 포함필터, 예외필터 같은걸 포함해줄 수 있다.

필터도 가끔 쓰인다. 내가 원하지 않는 건 스캔에서 회피하게 하거나(사실 이 용도) 등.

이렇게 대강 넘어가는 이유가 기본값에 맞춰서 쓰는것이 좋도록 애초에 만들어졌기 때문.

 

 

그 외에 빈으로 등록할 때 이름이 같아 발생하는 충돌 중 '자동 빈 등록 vs 자동 빈 등록'과 '자동 빈 등록 vs 수동 빈 등록'이 있는데 자동끼리는 충돌나고, 자동수동은 수동으로 덮어씌워지지만 스프링 전체를 실행할 땐 에러가 난다.