인프런 강의 68일차.

 - 스프링 핵심 원리 - 고급편 (김영한 강사님)

 - 반드시 한번은 정복해야할 쉽지 않은 내용들

 - 크게 3가지 고급 개념을 학습

  1. 스프링 핵심 디자인 패턴

     > 템플릿 메소드 패턴

     > 전략 패턴

     > 템플릿 콜백 패턴

     > 프록시 패턴

     > 데코레이터 패턴

  2. 동시성 문제와 쓰레드 로컬

     > 웹 애플리케이션

     > 멀티쓰레드

     > 동시성 문제

  3. 스프링 AOP

     > 개념, 용어정리

     > 프록시 - JDK 동적 프록시, CGLIB

     > 동작 원리

     > 실전 예제

     > 실무 주의 사항

 - 기타

     > 스프링 컨테이너의 확장 포인트 - 빈 후처리기

     > 스프링 애플리케이션을 개발하는 다양한 실무 팁

 - 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

4. 프록시 패턴과 데코레이터 패턴

 4.7. 데코레이터 패턴 - 예제 코드1

  - 데코레이터 패턴에 대해 이해하기

 - 프록시 패턴과 동일한 형태로 구현

package hello.proxy.puerproxy.decorator.code;

public interface Component {
    String operation();
}

 - hello.proxy.puerproxy.decorator.code.Component.java
 - 예제이므로 단순 메소드 하나만 구현

package hello.proxy.puerproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class RealComponent implements Component {

    @Override
    public String operation() {
        log.info("RealComponent 실행");
        return "data";
    }
}

 - hello.proxy.puerproxy.decorator.code.RealComponent.java

package hello.proxy.puerproxy.decorator;

import hello.proxy.puerproxy.decorator.code.DecoratorPatternClient;
import hello.proxy.puerproxy.decorator.code.RealComponent;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class DecoratorPatternTest {

    @Test
    void noDecorator() {
        RealComponent realComponent = new RealComponent();
        DecoratorPatternClient client = new DecoratorPatternClient(realComponent);
        client.execute();
    }

    @Test
    void Decorator() {
        RealComponent realComponent = new RealComponent();
        DecoratorPatternClient client = new DecoratorPatternClient(realComponent);
        client.execute();
    }
}

 - hello.proxy.puerproxy.decorator.DecoratorPatternTest.java

 - 테스트 코드는 client -> realComponent 의 의존관계를 설정하고, client.execute() 를 호출한다.

//실행 결과
RealComponent - RealComponent 실행
DecoratorPatternClient - result=data

 4.8. 데코레이터 패턴 - 예제 코드2

  - 프록시로 부가 기능을 추가하는 것을 데코레이터 패턴이라 한다 (서버가 제공하는 기능에 더해서 부가 기능을 수행)

    > 요청 값이나, 응답 값을 중간에 변형한다.

    > 실행 시간을 측정해서 추가 로그를 남긴다.

 - 응답 값을 꾸며주는 데코레이터 프록시를 만들어보자.

package hello.proxy.puerproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class MessageDecorator implements Component {

    private Component component;

    public MessageDecorator(Component component) {
        this.component = component;
    }

    @Override
    public String operation() {
        log.info("MessageDecorator 실행");

        String result = component.operation();
        String decoResult = "*****" + result + "*****";
        log.info("MessageDecorator 꾸미기 적용 전 ={} ,적용 후 ={}", result, decoResult);
        return decoResult;
    }
}

 - hello.proxy.puerproxy.decorator.code.MessageDecorator.java

public class DecoratorPatternTest {
	...
    @Test
    void decorator1() {
        RealComponent realComponent = new RealComponent();
        MessageDecorator messageDecorator = new MessageDecorator(realComponent);
        DecoratorPatternClient client = new DecoratorPatternClient(messageDecorator);
        client.execute();
    }
}

 - hello.proxy.puerproxy.decorator.DecoratorPatternTest.java

//실행 결과
MessageDecorator - MessageDecorator 실행
RealComponent - RealComponent 실행
MessageDecorator - MessageDecorator 꾸미기 적용 전=data, 적용 후=*****data*****
DecoratorPatternClient - result=*****data*****

 -  MessageDecorator 가 RealComponent 의 응답 메시지를 꾸며서 반환한 것을 확인할 수 있다.

 4.9. 데코레이터 패턴 - 예제 코드3

  - 실행 시간을 측정하는 데코레이터 구현

package hello.proxy.puerproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class TimeDecorator implements Component {

    private Component component;

    public TimeDecorator(Component component) {
        this.component = component;
    }

    @Override
    public String operation() {
        log.info("TimeDecorator 실행");
        long startTime = System.currentTimeMillis();
        String result = component.operation();
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("TimeDecorator 종료 resultTime={}ms", resultTime);
        return null;
    }
}

 - hello.proxy.puerproxy.decorator.code.TimeDecorator.java

public class DecoratorPatternTest {
	...
    @Test
    void decorator2() {
        RealComponent realComponent = new RealComponent();
        MessageDecorator messageDecorator = new MessageDecorator(realComponent);
        TimeDecorator timeDecorator = new TimeDecorator(messageDecorator);
        DecoratorPatternClient client = new DecoratorPatternClient(timeDecorator);
        client.execute();
    }
}

 - hello.proxy.puerproxy.decorator.DecoratorPatternTest.java

 - client -> timeDecorator -> messageDecorator -> realComponent 의 객체 의존관계를 세팅하고 실햄

//실행 결과
TimeDecorator 실행
MessageDecorator 실행
RealComponent 실행
MessageDecorator 꾸미기 적용 전=data, 적용 후=*****data*****
TimeDecorator 종료 resultTime=7ms
result=*****data*****

 - 실행 결과를 보면 TimeDecorator 가 MessageDecorator 를 실행하고 실행 시간을 측정해서 출력한 것을 확인할 수 있다

 4.10. 프록시 패턴과 데코레이터 패턴 정리

 - Decorator 기능에 일부 중복이 있다. 꾸며주는 역할을 하는 Decorator 들은 스스로 존재할 수 없이 항상 꾸며줄 대상이 있어야 한다.

 - 따라서 내부에 호출 대상인 component 를 가지고 있어야 한다. 그리고 component 를 항상 호출해야 한다.

 - 이 부분이 중복이다. 이런 중복을 제거하기 위해 component 를 속성으로 가지고 있는 Decorator 라는 추상 클래스를 만드는 방법도 고민할 수 있다.

 - 이렇게 하면 추가로 클래스 다이어그램에서 어떤 것이 실제 컴포넌트 인지, 데코레이터인지 명확하게 구분할 수 있다.

 - 여기까지 고민한 것이 바로 GOF에서 설명하는 데코레이터 패턴의 기본 예제이다.

* 프록시 패턴 vs 데코레이터 패턴

 - Decorator 라는 추상 클래스를 만들어야 데코레이터 패턴일까? 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 비슷한 것 같은데?

 - 패턴의 구분은 intent에 있다.

*의도(intent)

 - 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 같고, 상황에 따라 정말 똑같을 때도 있다.

 - 디자인 패턴에서 중요한 것은 해당 패턴의 겉모양이 아니라 그 패턴을 만든 의도가 더 중요하다.

 - 따라서 의도에 따라 패턴을 구분한다

* 프록시 패턴의 의도: 다른 개체에 대한 접근을 제어하기 위해 대리자를 제공

* 데코레이터 패턴의 의도: 객체에 추가 책임(기능)을 동적으로 추가하고, 기능 확장을 위한 유연한 대안 제공

 > 프록시를 사용하고 해당 프록시가 접근 제어가 목적이라면 프록시 패턴이고, 새로운 기능을 추가하는 것이 목적이라면 데코레이터 패턴이 된다.

인프런 강의 67일차.

 - 스프링 핵심 원리 - 고급편 (김영한 강사님)

 - 반드시 한번은 정복해야할 쉽지 않은 내용들

 - 크게 3가지 고급 개념을 학습

  1. 스프링 핵심 디자인 패턴

     > 템플릿 메소드 패턴

     > 전략 패턴

     > 템플릿 콜백 패턴

     > 프록시 패턴

     > 데코레이터 패턴

  2. 동시성 문제와 쓰레드 로컬

     > 웹 애플리케이션

     > 멀티쓰레드

     > 동시성 문제

  3. 스프링 AOP

     > 개념, 용어정리

     > 프록시 - JDK 동적 프록시, CGLIB

     > 동작 원리

     > 실전 예제

     > 실무 주의 사항

 - 기타

     > 스프링 컨테이너의 확장 포인트 - 빈 후처리기

     > 스프링 애플리케이션을 개발하는 다양한 실무 팁

 - 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

4. 프록시 패턴과 데코레이터 패턴

 4.3. 예제 프로젝트 만들기 V3

  - v3: 컴포넌트 스캔으로 스프링 빈 자동 등록

package hello.proxy.app.v3;

import org.springframework.stereotype.Repository;

@Repository
public class OrderRepositoryV3 {
    public void save(String itemId) {
        //저장 로직
        if( itemId.equals("ex")){
            throw new IllegalStateException("예외 발생!");
        }
        sleep(1000);
    }

    private void sleep(int millis) {
        try{
            Thread.sleep(millis);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
    }
}

 - hello.proxy.app.v3.OrderRepositoryV3.java

package hello.proxy.app.v3;

import org.springframework.stereotype.Service;

@Service
public class OrderServiceV3 {

    private final OrderRepositoryV3 orderRepository;

    public OrderServiceV3(OrderRepositoryV3 orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void orderItem(String itemId) {

    }
}

 - hello.proxy.app.v3.OrderServiceV3.java

package hello.proxy.app.v3;

import hello.proxy.app.v2.OrderServiceV3;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@Slf4j
@RestController
public class OrderControllerV3 {

    private final OrderServiceV3 orderService;

    public OrderControllerV3(OrderServiceV3 orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/v3/request")
    public String request(String itemId) {
        orderService.orderItem(itemId);
        return "ok";
    }

    @GetMapping("/v3/no-log")
    public String noLog() {
        return "ok";
    }
}

 - hello.proxy.app.v3.OrderControllerV3.java

 - ProxyApplication 에서 @SpringBootApplication(scanBasePackages = "hello.proxy.app") 를 사용했고, 각각 @RestController , @Service , @Repository 애노테이션을 가지고 있기 때문에 컴포넌트 스캔의 대상이 된다.

 4.4. 요구사항 추가

 * 기존 요구사항

   - 모든 PUBLIC 메서드의 호출과 응답 정보를 로그로 출력

   - 애플리케이션의 흐름을 변경하면 안됨

     > 로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨

   - 메서드 호출에 걸린 시간

   - 정상 흐름과 예외 흐름 구분

    > 예외 발생시 예외 정보가 남아야 함

   - 메서드 호출의 깊이 표현

   - HTTP 요청을 구분

     > HTTP 요청 단위로 특정 ID를 남겨서 어떤 HTTP 요청에서 시작된 것인지 명확하게 구분이 가능해야 함

     > 트랜잭션 ID (DB 트랜잭션X)

정상 요청
[530acbq7] OrderController.request()
[530acbq7] |-->OrderService.orderItem()
[530acbq7] | |-->OrderRepository.save()
[530acbq7] | |<--OrderRepository.save() time=1004ms
[530acbq7] |<--OrderService.orderItem() time=1014ms
[530acbq7] OrderController.request() time=1016ms
        
예외 발생
[f62121c63] OrderController.request()
[f62121c63] |-->OrderService.orderItem()
[f62121c63] | |-->OrderRepository.save()
[f62121c63] | |<X-OrderRepository.save() time=0ms
ex=java.lang.IllegalStateException: 예외 발생!
[f62121c63] |<X-OrderService.orderItem() time=10ms
ex=java.lang.IllegalStateException: 예외 발생!
[f62121c63] OrderController.request() time=11ms
ex=java.lang.IllegalStateException: 예외 발생!

 - 위 요구사항을 만족하기 위해서 기존 코드를 많이 수정해야 한다. 코드 수정을 최소화 하기 위해 템플릿 메서드 패턴과 콜백 패턴도 사용했지만, 결과적으로 로그를 남기고 싶은 클래스가 수백개라면 수백개의 클래스를 모두 고쳐야한다. 로그를 남길 때 기존 원본 코드를 변경해야 한다는 사실 그 자체가 개발자에게는 가장 큰 문제로 남는다.

 * 요구사항 추가

   - 원본 코드를 전혀 수정하지 않고, 로그 추적기를 적용

   - 특정 메서드는 로그를 출력하지 않는 기능

     > 보안상 일부는 로그를 출력하면 안됨

   - 다음과 같은 다양한 케이스에 적용할 수 있어야 한다.

    >  v1 - 인터페이스가 있는 구현 클래스에 적용

    >  v2 - 인터페이스가 없는 구체 클래스에 적용

    >  v3 - 컴포넌트 스캔 대상에 기능 적용

   - 가장 어려문 문제는 원본 코드를 전혀 수정하지 않고, 로그 추적기를 도입하는 것이다.

    > 이 문제를 해결하려면 프록시(Proxy)의 개념을 먼저 이해해야 한다.

 4.4. 프록시, 프록시 패턴, 데코레이터 패턴 - 소개

  - 프록시에 대해 이해하기

  - 일반적으로 Server에 대한 요청은 Client가 직접적으로 요청하는 형태이다. (직접호출)

  - Proxy는 Client가 Server에 바로 요청하지 않고, 중간에 있는 대리자를 통해 요청하는 형태이다. (간접호출)

 * 대체 가능

  - 아무 객체나 프록시가 될 수는 없다.

  - 객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지, 프록시에게 요청을 한 것인지 조차 몰라야 한다.

  - 즉, 서버와 프록시는 같은 인터페이스를 사용해야 한다. 그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다

  - 클래스 의존관계를 보면 클라이언트는 서버 인터페이스에만 의존한다.

  - 그리고 서버와 프록시가 같은 인터페이스를 사용한다. 따라서 DI를 사용해서 대체 가능하다.

 * 런타임 객체 의존 관계를 살펴보자. 

  - 런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 Client -> Server 에서 Client -> Proxy 로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 된다. 클라이언트 입장에서는 변경 사실 조차 모른다.

  - DI를 사용하면 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있다.

 * 프록시의 주요 기능 (크게 2가지로 구분됨)

   - 접근 제어

     > 권한에 따른 접근 차단

     > 캐싱

     > 지연 로딩

   - 부가 기능 추가

    >  원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다

    >  ex) 요청 값이나, 응답 값을 중간에 변형한다

    >  ex) 실행 시간을 측정해서 추가 로그를 남긴다

 * GOF 디자인 패턴

  - GOF 디자인 패턴에서는 프록시를 사용하는 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분한다.

    > 프록시 패턴: 접근 제어가 목적

    > 데코레이터 패턴: 새로운 기능 추가가 목적

 4.5. 프록시 패턴 - 예제 코드1

  - 테스트 코드에 Lombok 적용하기

    > build.gradle 에 테스트에서 lombok을 사용할 수 있도록 의존관계를 추가해야 한다.

dependencies {
	...
	//테스트에서 lombok 사용
	testCompileOnly 'org.projectlombok:lombok'
	testAnnotationProcessor 'org.projectlombok:lombok'
}

 * 프록시 패턴을 이해하기위한 예제코드를 작성하기 전  코드를 단순하게 만들어보자.

  - Client ->Subject Interface -> RealSubject Class 로 구현

package hello.proxy.puerproxy.proxy.code;

public interface Subject {
    String operation();
}

 - hello.proxy.puerproxy.proxy.code.Subject.java

 - 예제이므로 단순 메소드 하나만 구현

package hello.proxy.puerproxy.proxy.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class RealSubject implements Subject {
    
    @Override
    public String operation() {
        log.info("실제 객체 호출");
        sleep(1000);
        return "data";
    }

    private void sleep(int millis) {

        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

 - hello.proxy.puerproxy.proxy.code.RealSubject.java

 - RealSubject 는 Subject 인터페이스를 구현했다. operation() 은 데이터 조회 시 마다 1초가 걸리는 작업을 가정하기 위해 1초 sleep 을 걸었다.

package hello.proxy.puerproxy.proxy.code;

public class ProxyPatternClient {

    private Subject subject;

    public ProxyPatternClient(Subject subject) {
        this.subject = subject;
    }

    public void execute() {
        subject.operation();
    }
}

 - hello.proxy.puerproxy.proxy.code.ProxyPatternClient.java

 - Subject 인터페이스에 의존하고, Subject 를 호출하는 클라이언트 코드이다.

package hello.proxy.puerproxy.proxy;

import hello.proxy.puerproxy.proxy.code.ProxyPatternClient;
import hello.proxy.puerproxy.proxy.code.RealSubject;
import org.junit.jupiter.api.Test;

public class ProxyPatternTest {

    @Test
    void noProxyTest() {
        RealSubject realSubject = new RealSubject();
        ProxyPatternClient client = new ProxyPatternClient(realSubject);
        client.execute();
        client.execute();
        client.execute();
    }
}

 - hello.proxy.puerproxy.proxy.ProxyPatternTest.java

 - 테스트 코드에서는 client.execute() 를 3번 호출한다. 데이터를 조회하는데 1초가 소모되므로 총 3 초의 시간이 걸린다

 - client.execute() 결과가 한번 조회하면 변하지 않는 데이터라면 어딘가에 보관해두고 이미 조회한 데이터를 사용하는 것이 성능상 좋다. 이런 것을 캐시라고 한다.

 - 프록시 패턴의 주요 기능은 접근 제어이다. 캐시도 접근 자체를 제어하는 기능 중 하나이다.

 - 이미 개발된 로직을 전혀 수정하지 않고, 프록시 객체를 통해서 캐시를 적용해보자

 4.6. 프록시 패턴 - 예제 코드2

  - 프록시 패턴 적용

package hello.proxy.puerproxy.proxy.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class CacheProxy implements Subject {

    private Subject target;
    private String cacheValue;

    public CacheProxy(Subject target) {
        this.target = target;
    }

    @Override
    public String operation() {
        log.info("프록시 호출");
        if(cacheValue == null){
            cacheValue = target.operation();
        }

        return cacheValue;
    }
}

 - hello.proxy.puerproxy.proxy.code.CacheProxy.java

 - private Subject target : 클라이언트가 프록시를 호출하면 프록시가 최종적으로 실제 객체를 호출해야 한다. 따라서 내부에 실제 객체의 참조를 가지고 있어야 한다. 이렇게 프록시가 호출하는 대상을 target 이라 한다

 - operation() : 구현한 코드를 보면 cacheValue 에 값이 없으면 실제 객체( target )를 호출해서 값을 구한다. 그리고 구한 값을 cacheValue 에 저장하고 반환한다.

 - 만약 cacheValue 에 값이 있으면 실제 객체를 전혀 호출하지 않고, 캐시 값을 그대로 반환한다.

 - 따라서 처음 조회 이후에는 캐시( cacheValue ) 에서 매우 빠르게 데이터를 조회할 수 있다

public class ProxyPatternTest {
	...
    @Test
    void cacheProxyTest() {
        RealSubject realSubject = new RealSubject();
        CacheProxy cacheProxy = new CacheProxy(realSubject);
        ProxyPatternClient client = new ProxyPatternClient(cacheProxy);
        client.execute();
        client.execute();
        client.execute();
    }
}

 - hello.proxy.puerproxy.proxy.ProxyPatternTest.java

 - realSubject 와 cacheProxy을 연결하면 cacheProxy 가 realSubject 를 참조하는 런타임 객체 의존관계가 완성된다.

 - 그 뒤 client 에 cacheProxy 를 주입해서 client -> cacheProxy -> realSubject 런타임 객체 의존 관계를 만든다.

 - client.execute() 을 총 3번 호출하면 실제 realSubject 를 호출하는 것이 아니라 cacheProxy 를 호출하게 된다.

//실행 결과
CacheProxy - 프록시 호출
RealSubject - 실제 객체 호출
CacheProxy - 프록시 호출
CacheProxy - 프록시 호출

* exucte() 호출 흐름 

 - 1. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 없다 -> realSubject를 호출, 결과를 캐시에 저장 (1초)

 - 2. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 있다 -> cacheProxy에서 즉시 반환 (0초)

 - 3. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 있다 -> cacheProxy에서 즉시 반환 (0초)

  > 캐시 프록시를 도입하기 전에는 3초가 걸렸지만, 도입 이후에는 최초에 한번만 1 초가 걸리고, 이후에는 거의 즉시 반환

* 정리

 - 프록시 패턴의 핵심은 RealSubject 코드와 클라이언트 코드를 변경하지 않고, 프록시를 도입해서 접근 제어한다는 것이다

 - 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있다. 실제 클라이언트 입장에서는 프록시 객체가 주입되었는지, 실제 객체가 주입되었는지 알지 못한다

인프런 강의 66일차.

 - 스프링 핵심 원리 - 고급편 (김영한 강사님)

 - 반드시 한번은 정복해야할 쉽지 않은 내용들

 - 크게 3가지 고급 개념을 학습

  1. 스프링 핵심 디자인 패턴

     > 템플릿 메소드 패턴

     > 전략 패턴

     > 템플릿 콜백 패턴

     > 프록시 패턴

     > 데코레이터 패턴

  2. 동시성 문제와 쓰레드 로컬

     > 웹 애플리케이션

     > 멀티쓰레드

     > 동시성 문제

  3. 스프링 AOP

     > 개념, 용어정리

     > 프록시 - JDK 동적 프록시, CGLIB

     > 동작 원리

     > 실전 예제

     > 실무 주의 사항

 - 기타

     > 스프링 컨테이너의 확장 포인트 - 빈 후처리기

     > 스프링 애플리케이션을 개발하는 다양한 실무 팁

 - 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

4. 프록시 패턴과 데코레이터 패턴

 4.1. 프로젝트 생성

  - https://start.spring.io
  - 프로젝트 선택 Project : Gradle Project
  - Language : Java
  - Spring Boot : 2.7.0
  - Group : hello
  - Artifact : proxy
  - Name : proxy
  - Package name : hello.proxy
  - Packaging : Jar
  - Java : 11
  - Dependencies : Spring Web, Lombok
* gradle.build 실행 후 아래 오류 발생 시 gradle-wrapper.properties에서 gradle 버전을 6.9 이하로 변경해서 다운로드하자. (gradle-6.9-all.zip)
 > Unable to find method 'org.gradle.api.artifacts.result.ComponentSelectionReason.getDescription()Ljava/lang/String;'. Possible causes for this unexpected error include: Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.) Re-download dependencies and sync project (requires network)

 4.2. 예제 프로젝트 만들기 V1

  - 예제는 크게 3가지 상황으로 만든다.

    > v1 - 인터페이스와 구현 클래스 - 스프링 빈으로 수동 등록

    > v2 - 인터페이스 없는 구체 클래스 - 스프링 빈으로 수동 등록

    > v3 - 컴포넌트 스캔으로 스프링 빈 자동 등록

  - 실무에서는 스프링 빈으로 등록할 클래스는 인터페이스가 있는 경우도 있고 없는 경우도 있다.

  - 그리고 스프링 빈을 수동으로 직접 등록하는 경우도 있고, 컴포넌트 스캔으로 자동으로 등록하는 경우도 있다.

  - 이런 다양한 케이스에 프록시를 어떻게 적용하는지 알아보기 위해 다양한 예제를 준비해보자.

  -  v1 : 인터페이스와 구현 클래스 - 스프링 빈으로 수동 등록

package hello.proxy.app.v1;

public interface OrderRepositoryV1 {
    void save(String itemId);
}

package hello.proxy.app.v1;

public class OrderRepositoryV1Impl implements OrderRepositoryV1 {
    @Override
    public void save(String itemId) {
        //저장 로직
        if( itemId.equals("ex")){
            throw new IllegalStateException("예외 발생!");
        }
        sleep(1000);
    }

    private void sleep(int millis) {
        try{
            Thread.sleep(millis);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
    }
}

 - hello.proxy.app.v1.OrderRepositoryV1.java

 - hello.proxy.app.v1.OrderRepositoryV1Impl.java

package hello.proxy.app.v1;

public interface OrderServiceV1 {
    void orderItem(String itemId);
}

package hello.proxy.app.v1;

public class OrderServiceV1Impl implements OrderServiceV1 {

    private final OrderRepositoryV1 orderRepository;

    public OrderServiceV1Impl(OrderRepositoryV1 orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Override
    public void orderItem(String itemId) {

    }
}

 - hello.proxy.app.v1.OrderServiceV1.java

 - hello.proxy.app.v1.OrderServiceV1Impl.java

package hello.proxy.app.v1;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

@RequestMapping     //스프링은 @RequestMapping 혹은 @Controller가 있어야 스프링 컨트롤러로 인식
@ResponseBody
public interface OrderControllerV1 {

    @GetMapping("/v1/request")
    String request(@RequestParam("itemId") String itemId);

    @GetMapping("/v1/no-log")
    String noLog();
}

 - hello.proxy.app.v1.OrderControllerV1.java

 - @RequestMapping : 스프링MVC는 타입에 @Controller 또는 @RequestMapping 애노테이션이 있어야 스프링 컨트롤러로 인식한다. 그리고 스프링 컨트롤러로 인식해야, HTTP URL이 매핑되고 동작한다. 이 애노테이션은 인터페이스에 사용해도 된다.

 - @ResponseBody : HTTP 메시지 컨버터를 사용해서 응답한다. 이 애노테이션은 인터페이스에 사용해도 된다.

 - @RequestParam("itemId") String itemId : 인터페이스에는 @RequestParam("itemId") 의 값을 생략하면 itemId 단어를 컴파일 이후 자바 버전에 따라 인식하지 못할 수 있다.

 - 인터페이스에서는 꼭 넣어주자. 클래스에는 생략해도 대부분 잘 지원된다.

 - 코드를 보면 request() , noLog() 두 가지 메서드가 있다.

 - request() 는 LogTrace 를 적용할 대상이고, noLog() 는 단순히 LogTrace 를 적용하지 않을 대상이다.

package hello.proxy.app.v1;

public class OrderControllerV1Impl implements OrderControllerV1 {

    private final OrderServiceV1 orderService;

    public OrderControllerV1Impl(OrderServiceV1 orderService) {
        this.orderService = orderService;
    }

    @Override
    public String request(String itemId) {
        orderService.orderItem(itemId);
        return "ok";
    }

    @Override
    public String noLog() {
        return "ok";
    }
}

 - hello.proxy.app.v1.OrderControllerV1Impl.java

 - 컨트롤러 구현체이다. OrderControllerV1 인터페이스에 스프링MVC 관련 애노테이션이 정의되어 있다.

package hello.proxy.config;

import hello.proxy.app.v1.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppV1Config {

    @Bean
    public OrderControllerV1 orderControllerV1(){
        return new OrderControllerV1Impl(orderServiceV1());
    }

    @Bean
    public OrderServiceV1 orderServiceV1() {
        return new OrderServiceV1Impl(orderRepositoryV1());
    }

    @Bean
    public OrderRepositoryV1 orderRepositoryV1() {
        return new OrderRepositoryV1Impl();
    }
}

 - hello.proxy.config.AppV1Config.java

 - 스프링 Bean 수동 등록 config

package hello.proxy;

import hello.proxy.config.AppV1Config;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Import;

@Import(AppV1Config.class)
@SpringBootApplication(scanBasePackages = "hello.proxy.app") //주의 (설정 패키지 하위에서 컴포넌트 스캔 후 Bean을 자동등록한다)
public class ProxyApplication {

	public static void main(String[] args) {
		SpringApplication.run(ProxyApplication.class, args);
	}

}

 - hello.proxy.ProxyApplication.java

 - @Import(AppV1Config.class) : 클래스를 스프링 빈으로 등록한다.

 - 여기서는 AppV1Config.class 를 스프링 빈으로 등록한다.

 - 일반적으로 @Configuration 같은 설정 파일을 등록할 때 사용하지만, 스프링 빈을 등록할 때도 사용할 수 있다.

 - @SpringBootApplication(scanBasePackages = "hello.proxy.app") : @ComponentScan 의 기능과 같다.

 - 컴포넌트 스캔을 시작할 위치를 지정한다. 이 값을 설정하면 해당 패키지와 그 하위 패키지를 컴포넌트 스캔한다.

 - 이 값을 사용하지 않으면 ProxyApplication 이 있는 패키지와 그 하위 패키지를 스캔한다. 

 * 주의

  > @Configuration 은 내부에 @Component 애노테이션을 포함하고 있어서 컴포넌트 스캔의 대상이 된다.

  > 따라서 컴포넌트 스캔에 의해 hello.proxy.config 위치의 설정 파일들이 스프링 빈으로 자동 등록 되지 않도록 컴포넌스 스캔의 시작 위치를 scanBasePackages=hello.proxy.app 로 설정해야 수동 등록이 가능하다.

 4.2. 예제 프로젝트 만들기 V2

  - v2 : 인터페이스 없는 구현 클래스를 스프링 빈으로 수동 등록

package hello.proxy.app.v2;

public class OrderRepositoryV2 {
    public void save(String itemId) {
        //저장 로직
        if( itemId.equals("ex")){
            throw new IllegalStateException("예외 발생!");
        }
        sleep(1000);
    }

    private void sleep(int millis) {
        try{
            Thread.sleep(millis);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
    }
}

 - hello.proxy.app.v2.OrderRepositoryV2.java

package hello.proxy.app.v2;

public class OrderServiceV2 {

    private final OrderRepositoryV2 orderRepository;

    public OrderServiceV2(OrderRepositoryV2 orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void orderItem(String itemId) {

    }
}

 - hello.proxy.app.v2.OrderServiceV2.java

package hello.proxy.app.v2;

import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@Slf4j
@RequestMapping
@ResponseBody
public class OrderControllerV2 {

    private final OrderServiceV2 orderService;

    public OrderControllerV2(OrderServiceV2 orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/v2/request")
    public String request(String itemId) {
        orderService.orderItem(itemId);
        return "ok";
    }

    @GetMapping("/v2/no-log")
    public String noLog() {
        return "ok";
    }
}

 - hello.proxy.app.v2.OrderControllerV2.java

 - @Controller 를 사용하지 않고, @RequestMapping 애노테이션을 사용했다. 그 이유는 @Controller 를 사용하면 자동 컴포넌트 스캔의 대상이 되기 때문이다. 여기서는 컴포넌트 스캔을 통한 자동 빈 등록이 아니라 수동 빈 등록을 하는 것이 목표다. 따라서 컴포넌트 스캔과 관계 없는 @RequestMapping 를 타입에 사용했다.

package hello.proxy.config;

import hello.proxy.app.v2.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppV2Config {

    @Bean
    public OrderControllerV2 orderControllerV2(){
        return new OrderControllerV2(orderServiceV2());
    }

    @Bean
    public OrderServiceV2 orderServiceV2() {
        return new OrderServiceV2(orderRepositoryV2());
    }

    @Bean
    public OrderRepositoryV2 orderRepositoryV2() {
        return new OrderRepositoryV2();
    }
}

 - hello.proxy.config.AppV2Config.java

 - App별로 Config를 가져다 사용하도록 변경

 - 기존: @Import(AppV1Config.class)

 - 변경: @Import({AppV1Config.class, AppV2Config.class})

 - @Import 안에 배열로 등록하고 싶은 설정파일을 다양하게 추가할 수 있다.