[스프링 핵심 원리] 기본편2

📌 싱글톤 패턴

 : 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

 : 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야함 (ex. 생성자를 private으로 선언)

 : (-) 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다

 : (-) 의존관계상 클라이언트가 구체 클래스에 의존한다 ➡️ DIP 위반, OCP 위반 가능성 多

 : (-) 결론적으로 유연성 ↓

 

 

📌 싱글톤 컨테이너

: 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리

: 싱글톤 컨테이너는 싱글톤 레지스트리(싱글톤 객체를 생성하고 관리하는 기능)

: 스프링 빈이 싱글톤으로 관리되는 빈

- 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용!

 

❗ 싱글톤 방식의 주의점

 : 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다!

    - 특정 클라이언트에 의존적인 필드가 있으면 안된다.

    - 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.

    - 가급적 읽기만 가능해야 한다.

    - 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

❗ 스프링 컨테이너가 싱글톤을 보장해주는 이유 - @Configuration과 바이트코드 조작

: 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig클래스를 상속받는 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록!

: 그 임의의 다른 클래스가 싱글톤이 보장되도록 해줌!

- @Configuration을 사용하지 않으면 싱글톤 보장 X

 

 

📌 컴포넌트 스캔

: 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 기능

 

0️⃣ AppConfig.java (설정 파일) 만들기

@Configuration
@ComponentScan(
            excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = 
            Configuration.class)
)
public class AutoAppConfig {
}

- @ComponentScan 애노테이션 붙여주기

- excludeFilters를 이용해 설정 정보(@Configuration)는 컴포넌트 스캔 대상에서 제외

 

1️⃣ 스프링 빈으로 등록할 클래스에 @Component 애노테이션 붙이기 

@Component
public class MemoryMemberRepository implements MemberRepository {}

@Component
public class MemberServiceImpl implements MemberService {
    
    private final MemberRepository memberRepository;
    
    @Autowired
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

- @Autowired는 의존관계를 자동으로 주입

  → 기본 조회 전략은 타입이 같은 빈을 찾아서 주입 (getBean(MemberRepository.class)와 동일하다고 이해)

- 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용 (ex.memberServiceImpl)

*스프링 빈의 이름을 직접 지정하고 싶으면

@Component("memberService2")

 

❕컴포넌트 스캔 탐색 위치

@ComponentScan(
        basePackages = "hello.core",
}

- basePackages: 탐색할 패키지의 시작 위치를 지정 / basePackageClasses: 지정한 클래스의 패키지를 시작 위치로 지정

- 만약 지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치!

💡 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것을 권장!

 

❕컴포넌트 스캔 기본 대상

 - @Component

 - @Controller

 - @Service

 - @Repository : 스프링 데이터 접근 계층으로 인식, 데이터 계층의 예외를 스프링 예외로 변환

 - @Configuration : 스프링 설정 정보로 인식, 스프링 빈이 싱글톤으로 유지하도록 추가 처리

 

 

❕컴포넌트 스캔에 제외할 나만의 애노테이션을 만들어 보자!

0️⃣ 애노테이션 만들기

// 컴포넌트 스캔 대상에서 제외할 애노테이션
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {}

 

1️⃣ 원하는 클래스에 애노테이션 추가 

@MyExcludeComponent
public class BeanB {}

 

2️⃣ 설정 파일에 적용

@Configuration
@ComponentScan(
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
MyExcludeComponent.class)
)
static class ComponentFilterAppConfig {}

- includeFilters : 컴포넌트 스캔 대상을 추가로 지정

- excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정

 

✔️ @Component면 충분하기 때문에, includeFilters를 사용할 일은 거의 없다. 개인적으로 옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장!

 

 

📌 빈 중독 등록과 충돌

1) 자동 빈 등록 vs 자동 빈 등록

 : ConflictingBeanDefinitionException 예외 발생

 

2) 수동 빈 등록 vs 자동 빈 등록

 : 수동 빈 등록이 우선(수동 빈이 자동 빈을 오버라이딩)

 : 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생!

 

 

📌 의존관계 자동 주입

1️⃣ 생성자 주입

  - 생성자 호출시점에 딱 1번만 호출되는 것이 보장

  - 불변, 필수 의존관계에 사용

@Component
public class OrderServiceImpl implements OrderService {
    
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired // 생성자가 딱 1개 있으면 @Autowired 생략 가능!
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

 

💡 결론적으로, 생성자 주입을 사용해야 된다!

 - 대부분의 의존관계를 애플리케이션 종료 전까지 변하면 안됨. (불변)

 - 수정자 주입을 사용하면 setXxx메서드를 항상 public으로 열어두어야 한다. (좋은 설계 방법X)

 - 수정자 주입을 사용하면 순수한 자바 코드를 단위 테스트하는 경우 의존 관계가 없으면 실행은 되지만 결과가 올바르지 않음. but 생성자 주입을 사용하면 주입 데이터를 누락했을 때 컴파일 오류가 발생!

 

2️⃣ 수정자 주입(setter 주입)

  - 선택, 변경 가능성이 있는 의존관계에 사용

@Component
public class OrderServiceImpl implements OrderService {

    private MemberRepository memberRepository;     
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

*@Autowired의 기본 동작은 주입할 대상이 없으면 오류가 발생. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정!

 

3️⃣ 필드 주입

  - 코드가 간결하지만 외부에서 변경이 불가능해서 테스트하기 힘듬 (사용하지 말자!)

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;
}

 

4️⃣ 일반 메서드 주입

  - 한번에 여러 필드를 주입 받을 수 있음

 - 일반적으로 잘 사용X

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;

    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

❕ 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작. Member같은 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작 X

 

 

❗ 자동 주입 대상을 옵션으로 처리하는 방법

  - @Autowired(required = false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 X

  - org.springframework.lang.@Nullable: 자동 주입할 대상이 없으면 null이 입력

  - Optional<>: 자동 주입할 대상이 없으면 Optional.empty가 입력

// 호출 안됨
@Autowired(required = false)
public void setNoBean1(Member member) {
    System.out.println("setNoBean1 = " + member);
}

//null 호출
@Autowired
public void setNoBean2(@Nullable Member member) {
    System.out.println("setNoBean2 = " + member);
}

//Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
    System.out.println("setNoBean3 = " + member);
}

 

❗ 생성자 주입 시 final 키워드

 - 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에서 막아줌

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    //...
}

 

❔final 키워드

: 상수(constant)를 선언하는 키워드

: 상수는 한번 저장하면 다른 값으로 변경 X (선언과 동시에 초기화 권장!)

final int PI = 3.14

 

 

📌 롬복 라이브러리

- 롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어 줌

 

0️⃣ build.gradle 수정

//lombok 설정 추가 시작 
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    } 
}
//lombok 설정 추가 끝

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    
    //lombok 라이브러리 추가 시작
    compileOnly 'org.projectlombok:lombok' 
    annotationProcessor 'org.projectlombok:lombok'
    
    testCompileOnly 'org.projectlombok:lombok' 
    testAnnotationProcessor 'org.projectlombok:lombok' 
    //lombok 라이브러리 추가 끝
    
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    } 
}

- Preferences ➡️ plugin ➡️ lombok 검색 설치 실행 (재시작)

- Preferences ➡️ Annotation Processors ➡️ Enable annotation processing 체크 (재시작)

 

1️⃣ 코드 수정

- 기존

@Component
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

- 롬복 적용 후

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

 

💡 최근에는 생성자를 딱 1개 두고, @Autowired를 생략하는 방법을 주로 사용. 여기에 Lombok 라이브러리의 @RequiredArgsConstructor함께 사용하면 기능은 다 제공하면서, 코드는 깔끔하게 사용할 수 있음!

 

 

❗ 조회 빈이 2개 이상일 때

: @Autowired는 타입(Type)으로 조회하기 때문에 선택된 빈이 2개 이상이면 NoUniqueBeanDefinitionException 오류 발생!

→ 이 문제를 해결해보자!

 

1️⃣ @Autowired 필드 명 매칭

: @Autowired는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭함

// 기존 코드
@Autowired
private DiscountPolicy discountPolicy

// 필드 명을 빈 이름으로 변경
@Autowired
private DiscountPolicy rateDiscountPolicy

 

2️⃣ @Qualifier 사용

 : 추가 구분자를 붙여주는 방법. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아님

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                      @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

- @Qualifier끼리 매칭

- 빈 이름 매칭 (mainDiscountPolicy라는 스프링 빈을 추가로 검색)

- NoSuchBeanDefinitionException 예외 발생

 

3️⃣ @Primary 사용

: 우선순위를 정하는 방법. @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가짐.

 

💡 코드에서 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고, 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 한다면, 메일 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary를 적용하고, 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier를 지정해서 명시적으로 획득하는 방식을 취하면 좋다! (우선순위는 @Primary보다는 @Qualifier가 더 높다)

 

 

❗ 애노테이션을 직접 만들어 보자

: @Qualifier("mainDisxountPolicy")이렇게 문자를 적으면 컴파일시 타입 체크가 되지 않음!

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

- 애노테이션에는 상속이라는 개념X. 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능!

 

 

❗ 조회한 빈이 모두 필요할 때

public class AllBeanTest {

    @Test
    void findAllBean() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000,
"fixDiscountPolicy");
        
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
    
    static class DiscountService {
    
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        
        public DiscountService(Map<String, DiscountPolicy> policyMap,
List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }
        
        public int discount(Member member, int price, String discountCode) {
            
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            
            return discountPolicy.discount(member, price);
        } 
    }
}

- new AnnotationConfigApplicationContext()를 통해 스프링 컨테이너 생성!

- AutoAppConfig.class, DiscountService.class를 파라미터로 넘기면서 해당 클래스를 자동으로 스프링 빈으로 등록

  → 그래서 Map<String, DiscountPolicy>의 키에 스프링 빈의 이름, 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담을 수 있는 것! 

 

 

🙋🏻‍♀️ 그렇다면 언제 수동 빈 등록을 사용하고, 언제 자동 빈 등록을 사용해야 할까??

💡 편리한 자동 기능을 기본으로 사용하고 직접 등록하는 기술 지원 객체는 수동 등록하자! 그리고 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자!

 

 

📌 빈 생명주기 콜백

: 스프링 컨테이너 생성 ➡️ 스프링 빈 생성 ➡️ 의존관계 주입 ➡️ 초기화 콜백 ➡️ 사용 ➡️ 소멸 전 콜백 ➡️ 스프링 종료

 

1️⃣ 인터페이스(InitalizingBean, DisposableBean) 구현

public class NetworkClient implements InitializingBean, DisposableBean {
    
    private String url;
    
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url); 
    }
    
    public void setUrl(String url) {
        this.url = url;
    }
    
    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    
    //서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    
    @Override
    public void afterPropertiesSet() throws Exception {
        connect();
        call("초기화 연결 메시지");
    }
    
    @Override
    public void destroy() throws Exception {
        disConnect();
    }
}

- 스프링 전용 인터페이스(코드가 스프링 전용 인터페이스에 의존)

- 초기화, 소멸 메서드의 이름을 변경X

- 외부 라이브러리에 적용X

 

2️⃣ 설정 정보에 초기화 메서드, 종료 메서드 지정

@Configuration
static class LifeCycleConfig {
    
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    } 
}

- 메서드 이름을 자유롭게 줄 수 있음

- 스프링 빈이 스프링 코드에 의존X

- 외부 라이브러리에도 초기화, 종료 메서드를 적용O

 

❕ 종료 메서드 추론

- @Bean의 destroyMethod는 기본값이 (inferred)(추론)으로 등록

- close, shutdown라는 이름의 메서드를 자동으로 호출

- 추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정

 

3️⃣ @PostConstruct, @PreDestroy 애노테이션 지원 (권장)

public class NetworkClient {

    // ...
    
    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init"); connect();
        call("초기화 연결 메시지");
    }
    
    @PreDestroy
    public void close() {
        System.out.println("NetworkClient.close");
        disConnect();
    }
}

- 스프링에 종속적인 기술이 아니라 자바 표준 (스프링이 아닌 다른 컨테이너에서도 동작)

- 컴포넌트 스캔과 잘 어울림

- 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod, destroyMethod를 사용!

 

 

📌 빈 스코프

✔️ 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프

 

✔️ 프로토타입

 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

 

 

 

 

 

 

 

- 스프링 컨테이너에 요청할 때 마다 새로 생성

- 종료 메서드 호출X

 

❗싱글톤 빈과 함께 사용하면 프로토타입 빈이 싱글톤 빈처럼 동작 - 문제!!

💡 우리는 싱글톤 빈과 프로토타입 빈을 함께 사용할 때, 항상 새로운 프로토타입 빈을 생성해야 한다! Provider로 문제를 해결할 수 있다!

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject(); // DL
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

- DL(Dependency Lookup) : 의존관계를 외부에서 주입(DI) 받는게 아니라 직접 필요한 의존관계를 찾는 것

- ObjectProvider : ObjectFactory 상속, 옵션, 스트림 처리 등 편의 기능이 많고, 별도의 라이브러리 필요X. 스프링에 의존

❕ 이외에도 자바 표준인 JSR-330 Provider가 있지만, 코드를 스프링이 아닌 다른 컨테이너에서도 사용하는게 아니라면 ObjectProvider를 사용하자!

 

✔️ 웹 관련 스코프

- 웹 환경에서만 동작

- 스프링이 해당 스코프의 종료시점까지 관리(종료 메서드가 호출)

 - 웹 스코프 종류

    1) request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프

    2) session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프

    3) application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

// 컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {}

// 수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
    return new HelloBean();
}

 

 

❕ 웹 요청(request)이 오면 로그를 남기는 예제를 개발해보자!

 

0️⃣ web 환경이 동작하도록 build.gradle에 라이브러리를 추가

//web 라이브러리 추가
implementation 'org.springframework.boot:spring-boot-starter-web'

 

1️⃣ MyLogger 클래스 만들기

@Component
@Scope(value = "request")
public class MyLogger {
    
    private String uuid;
    private String requestURL;
    
    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;        
    }
    
    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " + message); 
    }
    
    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }
    
    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

- requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 setter로 입력 받음!

 

2️⃣ LogDemoController 클래스 만들기

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    
    private final LogDemoService logDemoService;
    private final MyLogger myLogger;
    
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }     
}

💡 requestURL을 MyLogger에 저장하는 부분은 컨트롤러 보다는 공통 처리가 가능한 스프링 인터셉터나 서블릿 필터 같은 곳을 활용하는 것이 좋음!

 

3️⃣ LogDemoService 클래스 만들기

@Service
@RequiredArgsConstructor
public class LogDemoService {
    
    private final MyLogger myLogger;
    
    public void logic(String id) {
        myLogger.log("service id = " + id);
    } 
}

- 서비스 계층은 웹 기술에 종속되지 않고, 가급적 순수하게 유지하는 것이 유지보수 관점에서 좋음(웹과 관련된 부분은 컨트롤러까지만!)

- 웹과 관련된 정보를 request scope의 MyLogger의 멤버변수에 저장해서 코드와 계층을 깔끔하게 유지!

 

❗ 애플리케이션을 실행하는 시점에서 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성X(실제 고객의 요청이 와야 생성 가능!)

    ➡️ 오류 발생

 

❕ 이 문제를 해결해보자!

✔️ Provider 사용

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    
    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider; // 달라진 부분
    
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        MyLogger myLogger = myLoggerProvider.getObject(); // 달라진 부분
        myLogger.setRequestURL(requestURL);
        
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    } 
}

@Service
@RequiredArgsConstructor
public class LogDemoService {
    
    private final ObjectProvider<MyLogger> myLoggerProvider; // 달라진 부분
    
    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject(); // 달라진 부분
        myLogger.log("service id = " + id);
    } 
}

- ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음

- ObjectProvider.getObject()를 LogDemoController, LogDemoService에 각각 한번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환!

 

✔️ 프록시 사용

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS) // 핵심!
public class MyLogger {
   // ...
}

- 적용 대상이 클래스면 TARGET_CLASS, 인터페이스면 INTERFACES를 선택

- MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있음!

 

🙋🏻‍♀️ 이게 어떻게 가능한걸까?

 : CGLIB(바이트코드를 조작하는 라이브러리)로 내 클래스(MyLogger)를 상속 받는 가짜 프록시 객체(ex. MyLogger$$EnhancerBySpringCGLIB)를 만들어서 주입

 : 스프링 컨테이너에 "myLogger"라는 이름 대신에 이 가짜 프록시 객체를 등록

 : ac.getBean("myLogger", MyLogger.class)로 조회해도 프록시 객체가 조회됨

 

✔️ 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음

   - 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고 있음

   - 클라이언트가 myLogger.log()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것

  - 가짜 프록시 객체는 request 스코프의 진짜 myLogger.log()를 호출

   - 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다(다형성)