위의 코드를 보면 공통 로직1과 공통 로직2는 호출하는 메소드만 다르고 전체 코드 흐름이 완전히 같다.먼저 start 로그를 출력한다.어떤 메소드를 호출한다.메소드의 호출 결과를 로그로 출력한다.여기서 공통 로직1과 공통 로직2를 하나의 메소드로 뽑아서 합칠 수 있을까
기존의 프록시는 프록시를 적용하기 위해 적용 대상의 숫자 만큼 많은 프록시 클래스를 만들었다.예를 들어 적용 대상이 100개면 프록시 클래스도 100개를 만들었다. 동적 프록시 기술을 사용하면 개발자가 직접 프록시 클래스를 만들지 않아도 된다.이름 그대로 프록시 객체를
CGLIB는 바이트코드를 조작해서 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리다.CGLIB를 사용하면 인터페이스가 없어도 구체 클래스만 가지고 동적 프록시를 만들어낼 수 있다.CGLIB는 원래 외부 라이브러리인데, 스프링 프레임워크가 스프링 내부 소스 코드에
스프링은 유사한 구체적인 기술들이 있을 때 그것들을 통합해서 일관성 있게 접근할 수 있고 더욱 편리하게 사용할 수 있는 추상화된 기술을 제공한다.스프링은 동적 프록시를 통합해서 편리하게 만들어주는 프록시 팩토리 라는 기능을 제공한다.이전에는 상황에 따라서 JDK 동적
어디에 부가 기능을 적용할지, 어디에 부가 기능을 적용하지 않을지 판단하는 필터링 로직이다. 주로 클래스와 메소드 이름으로 필터링 한다. 이름 그대로 어떤 포인트(Point)에 기능을 적용할지 하지 않을지 잘라서(cut) 구분하는 것이다. 프록시가 호출하는 부가 기능이
예제 코드 >- new DefaultPointcutAdvisor : Advisor 인터페이스의 가장 일반적인 구현체이다. 생성자를 통해 하나의 포인트 컷과 하나의 어드바이스를 넣어주면 된다. Pointcut.TRUE : 항상 true를 반환하는 포인트 컷이다. pro
@Bean이나 컴포넌트 스캔으로 스프링 빈으로 등록하면, 스프링은 대상 객체를 생성하고 스프링 컨테이너 내부의 빈 저장소에 등록한다. 그리고 이후에 스프링 컨테이너를 통해 등록한 빈을 조회해서 사용하면 된다.스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소
이 라이브러리를 추가하면 aspectjweaver라는 aspectJ 관련 라이브러리를 등록하고 스프링 부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록한다.스프링 부트가 없던 시절에는 @EnableAspectJWutoProxy를 직접 사용해야 했는데 이 부분을 스
스프링 애플리케이션에 프록시를 적용하러면 포인트컷과 어드바이스로 구성되어 있는 Advisor를 만들어서 스프링 빈으로 등록하면 된다. 그러면 나머지는 자동 프록시 생성기가 모두 자동으로 처리해준다. 자동 프록시 생성기는 스프링 빈으로 등록된 Advisor들을 찾고, 스
핵심 기능 : 해당 객체가 제공하는 고유의 기능이다. ex) OrderService 주문 로직부가 기능 : 핵심 기능을 보조하기 위해 제공되는 기능이다. ex) 로그 추적 로직, 트랜잭션 기능 이러한 부가 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용된다. e
Advice가 적용될 수 있는 위치, 메소드 실행, 생성자 호출, 필드 값 접근, static 메소드 접근 같은 프로그램 실행 중 지점 조인 포인트는 추상적인 개념이다. AOP를 적용할 수 있는 모든 지점이라고 생각하면 된다. 스프링 AOP는 프록시 방식을 사용하므로
@Around 애노테이션 값인 execution(\* hello.aop.order..\*(..))는 포인트컷이 된다.@Around 애노테이션의 메소드인 doLog는 Advice가 된다. execution(\* hello.aop.order..\*(..)) : hello.
포인트컷 지시자 > AspectJ는 포인트컷을 편리하게 표현하기 위한 특별한 표현식을 제공한다. ex) @Pointcut("execution (* hello.aop.order..*(..))") >포인트컷 표현식은 execution 같은 포인트컷 지시자(Pointcut
within > within 지시자는 특정 타입 내의 조인 포인트에 대한 매칭을 제한한다. 쉽게 이야기해서 해당 타입이 매칭되면 그 안에 메소드(조인 포인트)들이 자동으로 매칭된다. execution에서 타입 부분만 사용한다고 보면 된다. 예제 코드 > with
스프링은 프록시 방식의 AOP를 사용한다. 따라서 AOP를 적용하려면 항상 프록시를 통해 대상 객체(Target)을 호출해야 한다. 이렇게 해야 프록시에서 먼저 Advice를 호출하고 이후에 대상 객체를 호출한다.만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되
JDK 동적 프록시와 CGLIB를 사용해서 AOP 프록시를 만드는 방법에는 각각 장단점이 있다. JDK 동적 프록시는 인터페이스가 필수이고, 인터페이스 기반으로 프록시를 생성한다. CGLIB는 구체 클래스를 기반으로 프록시를 생성한다. 물론 인터페이스가 없고 구체클래스
JDK 동적 프록시를 사용하면서 의존관계를 주입할 때는 문제가 발생한다. 타입과 관련된 예외가 발생한다. membereServiceImpl에 주입되길 기대하는 타입은 hello.aop.member.service.MemberServiceImpl 이지만 실제 넘어온 타입은
대상 클래스에 기본 생성자가 필수다.생성자 2번 호출 문제가 발생한다. fianl 키워드 클래스, 메소드가 사용 불가하다. CGLIB는 구체 클래스를 상속 받는다. 자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 자식 클래스의 생성자에서 부모 클래스의 생
CGLIB를 사용하려면 CGLIB 라이브러리가 별도로 필요했다. 스프링은 CGLIB 라이브러리를 스프링 내부에 함께 패키징해서 별도의 라이브러리 추가 없이 CGLIB를 사용할 수 있게 되었다. 스프링 4.0부터 CGLIB의 기본 생성자가 필수인 문제가 해결되었다. ob