JArchive 프로그래밍 일기

목표

1. 컴포넌트 스캔과 의존관계 자동 주입 시작하기

2. 탐색 위치와 기본 스캔 대상

3. 필터 (이번 포스팅)

4. 중복 등록과 충돌 

3. 필터

1) 컴포넌트 스캔 필터에 쓸 애노테이션을 만들어보자. 

애노테이션 2개를 만드는데, '포함'한다는 의미로 MyIncludeComponent 라고 이름붙인다.

애노테이션 MyExcludeComponent 는 제외의 용도로 만든다. 

클래스 2개를 만들고 각각 다른 애노테이션을 붙인다.

BeanA 클래스에는 @MyIncludeComponent 를 붙인다. BeanB 에는 @MyExcludeComponent 를 붙인다. 

2) 컴포넌트 스캔에 필터를 적용한 테스트 코드를 작성한다.

@ComponentScan 에 includeFilters와 excludeFilters를 적용할 수 있다. 

includeFilters 에는 포함할 애노테이션인 MyIncludeComponent.class를 써주고,

excludeFilters 에는 제외하는 필터 애노테이션이니까 MyExcludeComponent.class를 써주자. 

3) 필터가 적용된 컴포넌트 스캔을 하되, 스프링 빈이 생성됬는지 확인하자.

BeanA만 컴포넌트 스캔에 포함되어야 한다.  BeanA 스프링 빈으로 등록되고,  BeanB 라는 빈은 찾을 수 없어야 테스트 성공이다. 

3) FilterType 옵션 5가지를 알아보자. 

* ANNOTATION  : 기본값. 애노테이션을 인식해서 동작하는 것이 기본이다. 

" type = FilterType.ANNOTATION "을 지워도 똑같이 동작한다. 

* ASSIONABLE_TYPE  : 지정한 타입과 자식 타입을 인식해서 동작한다 

    org.example.SomeClass

* ASPECTJ  : AspectJ 패턴을 사용한다 

    org.example..*Service+

* REGEX  : 정규표현식을 줄 수 있다 

    org\.example\.Default.*

* CUSTOM  : TypeFilter 라는 인터페이스를 구현해서 처리한다 

    org.example.MyTypeFilter

[ 참고 ]

@Component 애노테이션으로 충분하기 때문에 includeFilters 를 사용할 일은 드물다. excludeFilters는 아주 가끔 쓴다. 

스프링 부트가 기본으로 제공하는 컴포넌트 스캔을 사용하는 것을 권장한다. 

4. 중복 등록과 충돌

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 

다음 두 가지 상황이 있다.

1) 자동 빈 등록 vs 자동 빈 등록 

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록될 때 이름이 같으면 오류가 발생한다. 

예를 들어, 2개의 빈에 service라고 이름 붙여보자. 

MemberServiceImpl 과 OrderServiceImpl에 둘 다 @Component("service")라고 붙이자. 

컴포넌트 스캔을 해보면, 빈이 충돌난다고  ConflictingBeanDefinitionException  에러가 난다. 

org.springframework.beans.factory.BeanDefinitionStoreException: 
Failed to parse configuration class [hello.corebasic.AutoAppConfig]; 
nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: 

Annotation-specified bean name 'service' for bean class [hello.corebasic.order.OrderServiceImpl] conflicts with existing, 
non-compatible bean definition of same name and class [hello.corebasic.member.MemberServiceImpl]

에러 내용이 굉장히 친절하다. 애노테이션으로 이름지어진 'service'라는 빈 이름이 있는데,

MemberServiceImpl 에도 정의되어 있고, OrderServiceImpl 에도 같은 이름으로 정의되어 있다는 내용이다. 

2) 수동 빈 등록 vs 자동 빈 등록 

이 경우, 수동 빈 등록이 우선권을 가진다. 수동 빈이 자동 빈을 오버라이딩한다. 

예를 들어, MemoryMemberRepository는 @Component 를 달아놔서 컴포넌트 스캔의 대상이되고

빈 이름은 기본으로 클래스 명 앞글자 하나만 소문자로 바꿔서 memoryMemberRepository 로 이름지어진다. 

@ComponentScan 하는 설정에서 memoryMemberRepository라는 똑같은 이름으로 MemoryMemberRepository 빈 등록을 시도해보자. 

컴포넌트 스캔 하는 테스트를 실행하면? 성공하긴 한다. 

수동 빈이 자동 빈을 오버라이딩 한다고 로그 메시지가 출력된다. 

Overriding bean definition for bean 'memoryMemberRepository' with a different definition: 
replacing [Generic bean: class [hello.corebasic.member.MemoryMemberRepository];

하지만 현실은 개발자가 의도적으로 설정해서 이런 결과를 낳기보다는 여러 설정들이 꼬여서 이렇게 되는 경우가 다반사다!

이러면 정말 잡기 어려운 버그가 만들어진다. 항상 잡기 어려운 버그는 애매한 버그다. 

3) 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 이름 충돌이 나면 아래 내용의 오류를 내도록 바뀌었다. 

스프링 부트를 실행해보자. 

"이미 AutoAppConfig.class 에 정의된(수동으로 등록한) 'memoryMemberRepository' 빈이 등록되지 못했다. 

MemoryMemberRepository 에 정의된 이름으로 빈이 등록되었기 때문이다. 그리고 오버라이딩이 불가능하다. "

The bean 'memoryMemberRepository', 
defined in class path resource [hello/corebasic/AutoAppConfig.class], 
could not be registered. 
A bean with that name has already been defined in file [/Users/.../hello/corebasic
/member/MemoryMemberRepository.class] and overriding is disabled.

스프링 부트의 기본 설정으로는 이렇게 오류를 내지만, 

application.yml 애플리케이션 프로퍼티 파일에 옵션을 아래처럼 바꾸면 수동 등록 빈 오버라이딩을 허용해준다. 

Consider renaming one of the beans or enabling overriding by setting 
spring.main.allow-bean-definition-overriding=true

[ 참고 ] 

어설픈 추상화를 하지 말자. 코드 양이 좀더 나오더라도 명확하게 코딩하는 것이 낫다.

애매한 상황과 코드는 피해야 한다. 애매한 버그가 제일 잡기 어렵기 때문이다. 그리고 개발은 혼자하는 것이 아니기 때문이다. 

다음 강의에서는 다양한 의존관계 주입 방법을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편