WebMaster

AOP를 적용하는 3가지 방식 컴파일 시점 . java 소스 코드를 컴파일러를 사용해서. class를 만드는 시점에 부가 기능 로직을 추가할 수 있다. 이때는 AspectJ가 제공하는 특별한 컴파일러를 사용해야 한다. 컴파일된. class를 디컴파일 해보면 애스펙트 관련 호출 코드가 들어간다. 이해하기 쉽게 풀어서 이야기하면 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면 된다. AspectJ 컴파일러는 Aspect를 확인해서 해당 클래스가 적용 대상인지 먼저 확인하고, 적용 대상인 경우에 부가 기능 로직을 적용한다. 참고로 이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라 한다 단점 : 컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일..

핵심 기능과 부가 기능을 분리 누군가는 이러한 부가 기능 도입의 문제점들을 해결하기 위해 오랜 기간 고민해왔다. 그 결과 부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리하도록 했다. 그리고 해당 부가 기능을 어디에 적용할지 선택하는 기능도 만들었다. 이렇게 부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만들었는데 이것이 바로 애스펙트(aspect)이다. 애스펙트는 쉽게 이야기해서 부가 기능과, 해당 부가 기능을 어디에 적용할지 정의한 것이다. 예를 들어서 로그 출력 기능을 모든 컨트롤러에 적용해라 라는 것이 정의되어 있다 그렇다 바로 우리가 이전에 알아본 @Aspect 바로 그것이다. 그리고 스프링이 제공하는 어드바이저도 어드바이스(부가 기능)와 포인트 컷(적용 대상)..

핵심 기능과 부가 기능 애플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있다. 핵심 기능은 해당 객체가 제공하는 고유의 기능이다. 예를 들어서 OrderService의 핵심 기능은 주문 로직이다. 부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다. 예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 부가 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용된다. 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용한다. 그러니까 부가 기능은 이름 그대로 핵심 기능을 보조하기 위해 존재한다. 여러 곳에서 공통으로 사용하는 부가 기능 보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용된다. 예를 들어서 모든 애플리케이션 호출을 로깅해야 하는 요구사..

자동 프록시 생성기 ( AnnotationAwareAspectJAutoProxyCreator )는 Advisor를 자동으로 찾아와서 필요한 곳에 프록시를 생성하고 적용해준다고 했다. 자동 프록시 생성기는 여기에 추가로 하나의 역할을 더 하는데, 바로 @Aspect를 찾아서 이것을 Advisor로 만들어준다. 쉽게 이야기해서 지금까지 학습한 기능에 @Aspect를 Advisor로 변환해서 저장하는 기능도 한다. 그래서 이름 앞에 AnnotationAware (애노테이션을 인식하는)가 붙어 있는 것이다 자동 프록시 생성기는 2가지 일을 한다. @Aspect를 보고 어드바이저( Advisor )로 변환해서 저장한다. 어드바이저를 기반으로 프록시를 생성한다 @Aspect 를 어드바이저로 변환해서 저장하는 과정 ..

스프링 애플리케이션에 프록시를 적용하려면 포인트 컷과 어드바이스로 구성되어 있는 어드바이저 ( Advisor )를 만들어서 스프링 빈으로 등록하면 된다. 그러면 나머지는 앞서 배운 자동 프록시 생성기가 모두 자동으로 처리해준다. 자동 프록시 생성기는 스프링 빈으로 등록된 어드바이저들을 찾고, 스프링 빈 들에 자동으로 프록시를 적용해준다. (물론 포인트 컷이 매칭 되는 경우에 프록시를 생성한다.) 스프링은 @Aspect 애노테이션으로 매우 편리하게 포인트컷과 어드바이스로 구성되어 있는 어드바이저 생성 기능을 지원한다 @Slf4j @Aspect public class LogTraceAspect { private final LogTrace logTrace; public LogTraceAspect(LogTrac..

예를 들어서 어떤 스프링 빈이 advisor1 , advisor2 가 제공하는 포인트컷의 조건을 모두 만족하면 프록시 자동 생성기는 프록시를 몇 개 생성할까? 프록시 자동 생성기는 프록시를 하나만 생성한다. 왜냐하면 프록시 팩토리가 생성하는 프록시는 내부에 여러 advisor 들을 포함할 수 있기 때문이다. 따라서 프록시를 여러 개 생성해서 비용을 낭비할 이유가 없다. 프록시 자동 생성기 상황별 정리 advisor1 의 포인트컷만 만족 -> 프록시1개 생성, 프록시에 advisor1 만 포함 advisor1 , advisor2 의 포인트컷을 모두 만족 -> 프록시1개 생성, 프록시에 advisor1 , advisor2 모두 포함 advisor1 , advisor2 의 포인트컷을 모두 만족하지 않음 -> ..

build.gradle - 추가 implementation 'org.springframework.boot:spring-boot-starter-aop' 라이브러리를 추가하면 aspectjweaver라는 aspectJ 관련 라이브러리를 등록하고, 스프링 부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록한다. 스프링 부트가 없던 시절에는 @EnableAspectJAutoProxy 를 직접 사용해야 했는데, 이 부분을 스프링 부트가 자동으로 처리해준다. aspectJ는 뒤에서 설명한다. 스프링 부트가 활성화하는 빈은 AopAutoConfiguration를 참고하자 자동 프록시 생성기 - AutoProxyCreator 스프링 부트 자동 설정으로 AnnotationAwareAspectJAutoProxyCrea..

빈 후처리기를 통한 프록시 등록 @Slf4j public class PackageLogTracePostProcessor implements BeanPostProcessor { private final String basePackage; private final Advisor advisor; public PackageLogTracePostProcessor(String basePackage, Advisor advisor) { this.basePackage = basePackage; this.advisor = advisor; } @Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansExce..

public class BasicTest { @Test public void basicConfig() { ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BasicConfig.class); //A는 빈으로 등록된다. A a = applicationContext.getBean("beanA", A.class); a.helloA(); //B는 빈으로 등록되지 않는다. Assertions.assertThrows(NoSuchBeanDefinitionException.class, () -> applicationContext.getBean(B.class)); } @Slf4j @Configuration static class ..

@Bean이나 컴포넌트 스캔으로 스프링 빈을 등록하면, 스프링은 대상 객체를 생성하고 스프링 컨테이너 내부의 빈 저장소에 등록한다. 그리고 이후에는 스프링 컨테이너를 통해 등록한 스프링 빈을 조회해서 사용하면 된다 빈 후처리기 - BeanPostProcessor 스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소에 등록하기 직전에 조작하고 싶다면 빈 후처리기를 사용하면 된다. 빈 포스트 프로세서( BeanPostProcessor )는 번역하면 빈 후처리기인데, 이름 그대로 빈을 생성한 후에 무언가를 처리하는 용도로 사용한다. 객체를 조작할 수도 있고, 완전히 다른 객체로 바꿔치기 하는 것도 가능하다