스프링 어노테이션이 안 먹힐 때 의심해볼만한 것

대충 정리

1. BeanPostProcessor들은 순서를 가지고 있는 경우가 있고 ProxyCreator보다 internalAsyncBeanPostProcessor 등이 더 빠르다.

2. 내 경우에는 AppConfig @Configuration 클래스가 있고 여기에서 @EnableAsync, AsyncConfigurer설정과 WebMvcConfigurerAdapter 설정을 동시에 하고 있었다.

3. AppConfig는 몇몇 Interceptor 들을 Bean으로 등록하고 있었는데 그 Bean의 의존성 트리를 타고 올라가다 보면 나오는 클래스중 하나에서 Spring Cache를 사용하고 있는 상황이었다.

4. 그러다보니까 internalAsyncBeanPostProcessor을 설정하는 과정에서 AppConfig를 빈으로 만들어야했고, AppConfig를 빈으로 만들려면 당연히 Interceptor들과 그 의존성들도 모두 빈으로 만들어서 끌어와야되는 상황이 생겼다. 그에 따라 ProxyCreatorpost processor을 거치지 못한 채로 Spring Cache Annotation이 붙어있는 클래스들도 이미 bean으로 만들어져버리고 말았던 것이다.

5. 그에 따라 프록시가 아니라 그냥 bean이 application context에 들어가게 된다. 기본적으로 스프링의 bean은 singleton으로 관리되니까 뒤늦게 proxy로 만들어서 바꿔넣지도 않는다. 그럼 암만 어노테이션 붙여봤자 proxy 기반 기능들이 동작할 리가 없다.

따라서, 초기화 순서와 dependency 순서가 꼬이면 proxy가 아니라 그냥 instance가 bean으로 등록될 수 있으므로 @Cache든 @Async든 동작 안 하면 디버깅으로 @Autowired의 결과물이 proxy 인스턴스인지 그냥 class 인스턴스인지 확인해보고, proxy가 아니라면 dependency 순서 및 설정 초기화 순서를 다시 한번 점검해봐야한다

PostProcessorRegistrationDelegate

BeanPostProcessor 순서: PriorityOrdered, Ordered, 그리고 나머지

TODO: 나중에 좀 정리 필요