You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PackageLogTraceProxyProcessor는 원복 객체를 프록시 객체로 변환하는 역할을 한다. 이때 프록시 팩토리를 사용하는데, 프록시 팩토리는 advisor가 필요하기 때문에 이 부분은 외부에서 주입받는다.
모든 스프링 빈을 프록시를 적용할 필요 X → 특정패키지와 그 하위에 위치한 스프링 빈들만 프록시를 적용 다른 패키지의 객체들은 원본 객체를 그대로 반환
프록시 적용 대상의 반환 값을 보면 원본 객체 대신에 프록시 객체를 반환한다. → 스프링 컨테이너에 원본 객체 대신에 프록시 객체가 스프링 빈으로 등록된다. 원본 객체는 스프링 빈으로 등록되지 않는다.
packagehello.proxy.config.v4_postprocessor.postprocessor;
importlombok.extern.slf4j.Slf4j;
importorg.springframework.aop.Advisor;
importorg.springframework.aop.framework.ProxyFactory;
importorg.springframework.beans.BeansException;
importorg.springframework.beans.factory.config.BeanPostProcessor;
@Slf4jpublicclassPackageLogTraceProxyProcessorimplementsBeanPostProcessor {
privatefinalStringbasePackage;
privatefinalAdvisoradvisor;;
publicPackageLogTraceProxyProcessor(StringbasePackage, Advisoradvisor) {
this.basePackage = basePackage;
this.advisor = advisor;
}
@OverridepublicObjectpostProcessAfterInitialization(Objectbean, StringbeanName) throwsBeansException {
log.info("param beanName={} bean={}", beanName, bean.getClass());
//프록시 적용 대상 여부 체크//프록시 적용 대상이 아니면 원본은 그대로 반환StringpackageName = bean.getClass().getPackageName();
if (!packageName.startsWith(basePackage)) {
returnbean;
}
//프록시 대상이면 프록시를 만들어서 반환ProxyFactoryproxyFactory = newProxyFactory(bean);
proxyFactory.addAdvisor(advisor);
Objectproxy = proxyFactory.getProxy();
log.info("create proxy: target={} proxy={}", bean.getClass(), proxy.getClass());
returnproxy;
}
}
🗒️ BeanPostProcessorConfig
@import({AppV1Config.class, AppV2Config.class}) : V3는 컴포넌트 스캔으로 자동으로 스프링 빈으로 등록되지만, V1, V2 애플리케이션은 수동으로 스프링 빈으로 등록해야 동작한다.ProxyApplication에서 등록해도 되지만 편의상 여기에 등록하자.
@bean logTraceProxyPostProcessor() : 특정 패키지를 기준으로 프록시를 생성하는 빈 후처리기를 스프링 빈으로 등록한다. 빈 후처리기는 스프링 빈으로만 등록하면 자동으로 동작한다. 여기에 프록시를 적용할 패키지 정보(hello.proxy.app )와 어드바이저(getAdvisor(logTrace) )를 넘겨준다.
이제 프록시를생성하는코드가설정파일에는필요없다. 순수한 빈 등록만 고민하면 된다. 프록시를 생성하고 프록시를 스프링 빈으로 등록하는 것은 빈 후처리기가 모두 처리해준다.
여기서는 생략했지만, 실행해보면 스프링 부트가 기본으로 등록하는 수 많은 빈들이 빈 후처리기를 통과하는 것을 확인할 수 있다. 여기에 모두 프록시를 적용하는 것은 올바르지 않다. 꼭 필요한 곳에만 프록시를 적용해야 한다.
여기서는 basePackage 를 사용해서 v1~v3 애플리케이션 관련 빈들만 프록시 적용 대상이 되도록 했다.
v1: 인터페이스가 있으므로 JDK 동적 프록시가 적용된다.
v2: 구체 클래스만 있으므로 CGLIB 프록시가 적용된다.
v3: 구체 클래스만 있으므로 CGLIB 프록시가 적용된다.
컴포넌트스캔에도적용
여기서 중요한 포인트는 v1, v2와 같이 수동으로 등록한 빈 뿐만 아니라 컴포넌트 스캔을 통해 등록한 v3 빈들도 프록시를 적용할 수 있다는 점이다. 이것은 모두 빈 후처리기 덕분이다.
프록시 적용 대상 여부 체크
프록시 적용 대상 여부 체크애플리케이션을 실행해서 로그를 확인해보면 알겠지만, 우리가 직접 등록한 스프링 빈들 뿐만 아니라 스프링 부트가 기본으로 등록하는 수 많은 빈들이 빈 후처리기에 넘어온다. 그래서 어떤 빈을 프록시로 만들 것인지 기준이 필요하다. 여기서는 간단히 basePackage 를 사용해서 특정 패키지를 기준으로 해당 패키지와 그 하위 패키지의 빈들을 프록시로 만든다.
스프링 부트가 기본으로 제공하는 빈 중에는 프록시 객체를 만들 수 없는 빈들도 있다. 따라서 모든 객체를 프록시로 만들 경우 오류가 발생한다
5️⃣ 빈 후처리기 - 정리
🗒️ 문제 1 - 너무 많은 설정
🗒️ 문제 2 - 컴포넌트 스캔
🗒️ 문제 해결
6️⃣ 스프링이 제공하는 빈 후처리기 1
주의 - 다음을꼭추가해주어야한다.**
✅ build.gradle - 추가
implementation org.springframework.boot:spring-boot-starter-aop'이 라이브러리를 추가하면 aspectjweaver 라는 aspectJ 관련 라이브러리를 등록하고, 스프링 부트가 AOP 관련
클래스를 자동으로 스프링 빈에 등록한다. 스프링 부트가 없던 시절에는 @EnableAspectJAutoProxy 를 직접 사용해야 했는데, 이 부분을 스프링 부트가 자동으로 처리해준다. aspectJ 는 뒤에서 설명한다. 스프링 부트가 활성화하는
빈은 AopAutoConfiguration 를 참고하자.
✅ 자동프록시생성기 - AutoProxyCreator
앞서 이야기한 스프링 부트 자동 설정으로 AnnotationAwareAspectJAutoProxyCreator 라는 빈 후처리기가 스프링 빈에 자동으로 등록된다.
이름 그대로 자동으로 프록시를 생성해주는 빈 후처리기이다.
이 빈 후처리기는 스프링 빈으로 등록된 Advisor 들을 자동으로 찾아서 프록시가 필요한 곳에 자동으로 프록시를 적용해준다.
Advisor 안에는 Pointcut 과 Advice 가 이미 모두 포함되어 있다. 따라서 Advisor 만 알고 있으면 그 안
에 있는Pointcut으로 어떤 스프링 빈에 프록시를 적용해야 할지 알 수 있다. 그리고 Advice로 부가 기능을
적용하면 된다.
✅ 자동프록시생성기의작동과정을알아보자
생성: 스프링이 스프링 빈 대상이 되는 객체를 생성한다. (@bean , 컴포넌트 스캔 모두 포함)
전달: 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달한다.
모든 Advisor 빈조회: 자동 프록시 생성기 - 빈 후처리기는 스프링 컨테이너에서 모든 Advisor 를 조회한다.
프록시적용대상체크: 앞서 조회한 Advisor 에 포함되어 있는 포인트컷을 사용해서 해당 객체가 프록시를
적용할 대상인지 아닌지 판단한다. 이때 객체의 클래스 정보는 물론이고, 해당 객체의 모든 메서드를 포인트컷에 하나하나 모두 매칭해본다. 그래서 조건이 하나라도 만족하면 프록시 적용 대상이 된다. 예를 들어서 10개의 메서드 중에 하나만 포인트컷 조건에 만족해도 프록시 적용 대상이 된다.
프록시생성: 프록시 적용 대상이면 프록시를 생성하고 반환해서 프록시를 스프링 빈으로 등록한다. 만약 프록시 적용 대상이 아니라면 원본 객체를 반환해서 원본 객체를 스프링 빈으로 등록한다.
빈등록: 반환된 객체는 스프링 빈으로 등록된다
중요: 포인트컷은 2가지에사용된다.
프록시적용여부판단 - 생성단계
자동 프록시 생성기는 포인트컷을 사용해서 해당 빈이 프록시를 생성할 필요가 있는지 없는지 체크한다.
클래스 + 메서드 조건을 모두 비교한다. 이때 모든 메서드를 체크하는데, 포인트컷 조건에 하나하나 매칭해본다. 만약 조건에 맞는 것이 하나라도 있으면 프록시를 생성한다.예) orderControllerV1 은 request() , noLog() 가 있다. 여기에서 request() 가 조건에
만족하므로 프록시를 생성한다.
만약 조건에 맞는 것이 하나도 없으면 프록시를 생성할 필요가 없으므로 프록시를 생성하지 않는다.
어드바이스적용여부판단 - 사용단계
프록시가 호출되었을 때 부가 기능인 어드바이스를 적용할지 말지 포인트컷을 보고 판단한다.
앞서 설명한 예에서 orderControllerV1 은 이미 프록시가 걸려있다.
orderControllerV1 의 request() 는 현재 포인트컷 조건에 만족하므로 프록시는 어드바이스를 먼저 호출하고, target 을 호출한다.
orderControllerV1의 noLog() 는 현재 포인트컷 조건에 만족하지 않으므로 어드바이스를 호출하지 않고 바로 target 만 호출한다.
참고: 프록시를 모든 곳에 생성하는 것은 비용 낭비이다. 꼭 필요한 곳에 최소한의 프록시를 적용해야 한다. 그래서 자동
프록시 생성기는 모든 스프링 빈에 프록시를 적용하는 것이 아니라 포인트컷으로 한번 필터링해서 어드바이스가 사용될가능성이 있는 곳에만 프록시를 생성한다.
애플리케이션 서버를 실행해보면, 스프링이 초기화 되면서 기대하지 않은 이러한 로그들이 올라온다. 그 이유는 지금 사용한 포인트컷이 단순히 메서드 이름에 "request*", "order*", "save*" 만 포함되어 있으면 매칭 된다고 판단하기 때문이다.결국 스프링이 내부에서 사용하는 빈에도 메서드 이름에 request 라는 단어만 들어가 있으면 프록시가 만들어지고 되고, 어드바이스도 적용되는 것이다
AspectJExpressionPointcut AspectJ라는 AOP에 특화된 포인트컷 표현식을 적용할 수 있다. AspectJ 포인트컷 표현식과 AOP는 조금 뒤에 자세히 설명하겠다. 지금은 특별한 표현식으로 복잡한 포인트컷을 만들 수 있구나 라고 대략 이해하면 된다.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
4️⃣ 빈 후처리기 - 적용
빈 후처리기를 사용해서 실제 객체 대신 프록시를 스프링 빈으로 등록해보자.
수동으로 등록하는 빈, 컴포넌트 스캔을 사용하는 빈까지 모두 프록시를 적용할 수 있다.
더불어 설정 파일에 있는 수 많은 프록시 생성 코드도 한번에 제거할 수 있다.
빈 후처리기 - 프록시 적용 그림
🗒️ PackageLogTraceProxyProcessor
🗒️ BeanPostProcessorConfig
🗒️ ProxyApplication
🗒️ 실행 결과
여기서는 생략했지만, 실행해보면 스프링 부트가 기본으로 등록하는 수 많은 빈들이 빈 후처리기를 통과하는 것을 확인할 수 있다. 여기에 모두 프록시를 적용하는 것은 올바르지 않다. 꼭 필요한 곳에만 프록시를 적용해야 한다.
여기서는
basePackage를 사용해서 v1~v3 애플리케이션 관련 빈들만 프록시 적용 대상이 되도록 했다.v1: 인터페이스가 있으므로 JDK 동적 프록시가 적용된다.
v2: 구체 클래스만 있으므로 CGLIB 프록시가 적용된다.
v3: 구체 클래스만 있으므로 CGLIB 프록시가 적용된다.
컴포넌트 스캔에도 적용
프록시 적용 대상 여부 체크
스프링 부트가 기본으로 제공하는 빈 중에는 프록시 객체를 만들 수 없는 빈들도 있다. 따라서 모든 객체를 프록시로 만들 경우 오류가 발생한다
5️⃣ 빈 후처리기 - 정리
🗒️ 문제 1 - 너무 많은 설정
🗒️ 문제 2 - 컴포넌트 스캔
🗒️ 문제 해결
6️⃣ 스프링이 제공하는 빈 후처리기 1
주의 - 다음을 꼭 추가해주어야 한다.**
✅ build.gradle - 추가
@EnableAspectJAutoProxy를 직접 사용해야 했는데, 이 부분을 스프링 부트가 자동으로 처리해준다.aspectJ는 뒤에서 설명한다. 스프링 부트가 활성화하는✅ 자동 프록시 생성기 - AutoProxyCreator
Advisor 안에는 Pointcut 과 Advice 가 이미 모두 포함되어 있다. 따라서
Advisor만 알고 있으면 그 안에 있는Pointcut으로 어떤 스프링 빈에 프록시를 적용해야 할지 알 수 있다. 그리고
Advice로 부가 기능을적용하면 된다.
✅ 자동 프록시 생성기의 작동 과정을 알아보자
Advisor를 조회한다.중요: 포인트컷은 2가지에 사용된다.
프록시 적용 여부 판단 - 생성 단계
orderControllerV1은 request() , noLog() 가 있다. 여기에서 request() 가 조건에어드바이스 적용 여부 판단 - 사용 단계
7️⃣ 스프링이 제공하는 빈 후처리기 2
애플리케이션 서버를 실행해보면, 스프링이 초기화 되면서 기대하지 않은 이러한 로그들이 올라온다. 그 이유는 지금 사용한 포인트컷이 단순히 메서드 이름에
"request*", "order*", "save*"만 포함되어 있으면 매칭 된다고 판단하기 때문이다.결국 스프링이 내부에서 사용하는 빈에도 메서드 이름에request라는 단어만 들어가 있으면 프록시가 만들어지고 되고, 어드바이스도 적용되는 것이다AspectJExpressionPointcut AspectJ라는 AOP에 특화된 포인트컷 표현식을 적용할 수 있다. AspectJ 포인트컷 표현식과 AOP는 조금 뒤에 자세히 설명하겠다. 지금은 특별한 표현식으로 복잡한 포인트컷을 만들 수 있구나 라고 대략 이해하면 된다.
Beta Was this translation helpful? Give feedback.
All reactions