[스프링 핵심 원리 - 기본편] 9. 빈 스코프

📌 빈 스코프란?

스프링 빈은 스프링 컨테이너의 시작과 함께 생성돼서 스프링 컨테이너가 종료될 때 까지 유지됨
스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문

 

✔ 스코프 : 빈이 존재할 수 있는 범위

 

⚡ 스프링이 지원하는 다양한 스코프

• 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
• 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
• 웹 관련 스코프
  • request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프
  • session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
  • application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

 

⚡ 빈 스코프 지정 방법

컴포넌트 스캔 자동 등록

@Scope("prorotype")
@Component
public class HelloBean{}

 

수동 등록

@Scope("prototype")
@Bean
PrototypeBean HelloBean(){
    return new HelloBean();
}

 

➡️ 지금까지 배운건 전부 싱글톤 스코프

 

 

📌 프로토타입 스코프

 

✔ 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링을 반환함

✔ 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환함

 

⚡ 싱글톤 빈 요청

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청함
2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환함
3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환함

 

⚡ 프로토타입 빈 요청

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청함
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입함

 

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환함
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환함

 

정리

• 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리
• 클라이언트에 빈을 반환하고, 이후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않음
• 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있음
  • @PreDestroy같은 종료 메서드가 호출되지 않음

 

 

⚡ 싱글톤 스코프 빈 테스트

🔶 test/.../hello.core/scope/SingletonTest

package hello.core.scope;

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import static org.assertj.core.api.Assertions.*;

public class SingletonTest {

    @Test
    void singletonBeanFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);

        SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
        SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);

        System.out.println("singletonBean1 = " + singletonBean1);
        System.out.println("singletonBean2 = " + singletonBean2);

        assertThat(singletonBean1).isSameAs(singletonBean2);

        ac.close();
    }

    @Scope("singleton")
    static class SingletonBean{
        @PostConstruct
        public void init(){
            System.out.println("SingletonBean.init");
        }

        @PreDestroy
        public void destroy(){
            System.out.println("SingletonBean.destroy");
        }
    }
}

 

실행 결과

SingletonBean.init
singletonBean1 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
singletonBean2 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
org.springframework.context.annotation.AnnotationConfigApplicationContext -Closing SingletonBean.destroy

• 빈 초기화 메서드를 실행
  • 같은 인스턴스의 빈 조회
  • 종료메서드까지 정상 호출

 

⚡ 프로토타입 스코프 빈 테스트

🔶 PrototypeTest

package hello.core.scope;

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import static org.assertj.core.api.Assertions.assertThat;

public class PrototypeTest {

    @Test
    void prototypeBeanFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);

        System.out.println("find prototypeBean1");
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        System.out.println("find prototypeBean2");
        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);

        System.out.println("prototypeBean1 = " + prototypeBean1);
        System.out.println("prototypeBean2 = " + prototypeBean2);

        assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
        ac.close();
    }

    @Scope("prototype")
    static class PrototypeBean{
        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init");
        }

        @PreDestroy
        public void destroy(){
            System.out.println("PrototypeBean.destroy");
        }
    }
}

 

실행 결과

find prototypeBean1
PrototypeBean.init
find prototypeBean2
PrototypeBean.init
prototypeBean1 = hello.core.scope.PrototypeTest$PrototypeBean@13d4992d
prototypeBean2 = hello.core.scope.PrototypeTest$PrototypeBean@302f7971     org.springframework.context.annotation.AnnotationConfigApplicationContext -Closing

• 싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행되지만, 프로토타입 스코프의 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화 메서드도 실행됨
• 프로토타입 빈을 2번 조회했으므로 완전히 다른 스프링 빈이 생성되고, 초기화도 2번 실행된 것을 확인할 수 있음
• 싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료 메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화까지만 관여하고, 더는 관리하지 않음
  • 프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestroy같은 종료 메서드가 전혀 실행되지 않음

 

prototypeBean1.destroy();
prototypeBean2.destroy();

• 수동으로 직접 호출해줘야 함

 

⚡ 프로토타입 빈의 특징 정리

• 스프링 컨테이너에 요청할 때마다 새로 생성됨
• 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여함
• 종료메서드가 호출되지 않음
  • 프로토타입 빈을 조회한 클라이언트가 관리해야함
  • 종료메서드에 대한 호출도 클라이언트가 직접 해야함

 

 

📌 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

 

✔ 스프링 컨테이너에 프로토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환함

• 싱글톤 빈과 함께 사용 시에는 의도한 대로 잘 동작되지 않음

 

⚡ 스프링 컨테이너에 프로토타입 빈을 직접 요청하는 예시

스프링 컨테이너에 프로토타입 직접 요청(1)

1. 클라이언트 A는 스프링 컨테이너에 프로토타입 빈을 요청
2. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환(x01)함

• 해당 빈의 count 필드값은 0임

3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count 필드를 +1함

 

❗ 결과적으로 프로토타입 빈(x01)의 count는 1이 됨

 

스프링 컨테이너에 프로토타입 직접 요청(2)

1. 클라이언트 B는 스프링 컨테이너에 프로토타입 빈을 요청
2. 스프링 컨테이너느 프로토타입 빈을 새로 생성해서 반환(x02)함

• 해당 빈의 count 필드값은 0임

3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count 필드를 +1함

❗ 결과적으로 프로토타입 빈(x02)의 count는 1이 됨

 

코드

🔶 SingletonWithPrototype1 

package hello.core.scope;

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import static org.assertj.core.api.Assertions.*;

public class SingletonWithPrototype1 {

    @Test
    void prototypeFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        prototypeBean1.addCount();
        assertThat(prototypeBean1.getCount()).isEqualTo(1);

        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
        prototypeBean2.addCount();
        assertThat(prototypeBean2.getCount()).isEqualTo(1);


    }

    @Scope("prototype")
    static class PrototypeBean{
        private int count = 0;

        public void addCount(){
            count++;
        }
        public int getCount(){
            return count;
        }

        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init " + this);
        }
        @PreDestroy
        public void destroy(){
            System.out.println("PrototypeBean.destroy");
        }
    }
}

 

⚡ 싱글톤 빈에서 프로토타입 빈 사용

✔clientBean이라는 싱글톤 빈이 의존관계 주입을 통해서 프로토타입 빈을 주입받아서 사용하는 예시

 

싱글톤에서 프로토타입 빈 사용(1)

 

✔ clientBean은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생함

 

1. clientBean은 의존관계 자동 주입을 사용함
   • 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청함

2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean에 반환함
   • 프로토타입 빈의 count 필드 값은 0임

✔ 이제 clientBean은 프로토타입 빈을 내부 필드에 보관함(정확히는 참조값 보관)

 

싱글톤에서 프로토타입 빈 사용(2)

 

• 클라이언트 A는 clientBean을 스프링 컨테이너에 요청해서 받음
  • 싱글톤이므로 항상 같은 clientBean이 반환됨

3. 클라이언트 A는 clientBean.logic()을 호출함
4. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가함
   • count = 1이 됨

 

싱글톤에서 프로토타입 빈 사용(3)

 

• 클라이언트 B는 clientBean을 스프링 컨테이너에 요청해서 받음
  • 싱글톤이므로 항상 같은 clientBean이 반환됨

❗clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈임

-> 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성된 것이지, 사용할 때마다 새로 생성되는 것이 아님!!

5. 클라이언트 B는 clientBean.logic()을 호출함
6. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가함

• 원래 count 값이 1이었으므로 2가 됨

 

코드

🔶 SingletonWithPrototype1.java 코드 수정

package hello.core.scope;

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import static org.assertj.core.api.Assertions.*;

public class SingletonWithPrototype1 {

    @Test
    void prototypeFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        prototypeBean1.addCount();
        assertThat(prototypeBean1.getCount()).isEqualTo(1);

        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
        prototypeBean2.addCount();
        assertThat(prototypeBean2.getCount()).isEqualTo(1);


    }

    @Test
    void singletonClientUsePrototype(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class, ClientBean.class);
        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        assertThat(count1).isEqualTo(1);

        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        assertThat(count2).isEqualTo(2);

    }

    @Scope("singleton")
    static class ClientBean{
        private final PrototypeBean prototypeBean;

        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
            this.prototypeBean = prototypeBean;
        }
        public int logic(){
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }


    }
    @Scope("prototype")
    static class PrototypeBean{
        private int count = 0;

        public void addCount(){
            count++;
        }
        public int getCount(){
            return count;
        }

        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init " + this);
        }
        @PreDestroy
        public void destroy(){
            System.out.println("PrototypeBean.destroy");
        }
    }
}

 

✔ 스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 됨

• 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것이 문제임

✔ 프로토타입 빈을 주입 시점에만 새로 생성하는 것이 아니라, 사용할 때마다 새로 생성해서 사용하는 것을 원함

 

💡 cf)
여러 빈에서 같은 프로토타입 빈을 주입받으면, 주입받는 시점에 각각 새로운 프로토타입 빈이 생성됨

ex)
clientA, clientB가 각각 의존관계 주입을 받으면 각각 다른 이스턴스의 프로토타입 빈을 주입받음
clientA -> prototypeBean@x01
clientB -> prototypeBean@x02
물론 사용할 때마다 새로 생성되는 것은 아님

 

📌 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Privider로 문제 해결

✔ 사용할 때마다 항상 새로운 프로토타입 빈을 생성하기 위해선?

 

⚡ 스프링 컨테이너에 요청

✔ 가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것

public class PrototypeProviderTest {

    @Test
    void providerTest() {
           AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);

        ClientBean clientBean1 = ac.getBean(ClientBean.class);

        int count1 = clientBean1.logic();
        assertThat(count1).isEqualTo(1);
        ClientBean clientBean2 = ac.getBean(ClientBean.class);

        int count2 = clientBean2.logic();
        assertThat(count2).isEqualTo(1);
    }

    static class ClientBean {
        @Autowired
        private ApplicationContext ac;

        public int logic() {
            PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
         @Scope("prototype")
          static class PrototypeBean {
            private int count = 0;
            public void addCount() {
                count++;
            }

            public int getCount() {
                return count;
            }

            @PostConstruct
              public void init() {
                System.out.println("PrototypeBean.init " + this);
              }

              @PreDestroy
              public void destroy() {
                System.out.println("PrototypeBean.destroy");
              }
        } 
    }
}

 

 

핵심 코드

@Autowired
private ApplicationContext ac;

public int logic() {
    PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

• 실행해보면 ac.getBean()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음
• 의존관계를 외부에서 주입(DI)받는 것이 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL) 의존관계 조회(탐색)이라고 함
• but, 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위테스트도 어려워짐
• 지금 필요한 기능은 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 딱! DL 정도의 기능만 제공하는 무언가가 있으면 됨
• (스프링에는 모든게 있음)

 

 

⚡ ObjectFactory, ObjectProvider

🔶 SingletonWithPrototype1.java 코드 수정

@Scope("singleton")
static class ClientBean{

    @Autowired
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

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

• 실행해보면 prototypeBeanProvider.getObject()를 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음
• ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함(DL)
• 스프링이 제공하는 기능을 사용하지만, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워짐
• ObjectProvider는 지금 딱 필요한 DL 정도의 기능만 제공
• ObjectProvider를 ObjectFactory로 바꿔도 됨

 

특징

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

 

⚡ JSR-330 Provider

• 마지막 방법은 javax.inject.Provider라는 JSR-330 자바 표준을 사용하는 방법
• 스프링 부트 3.0은 jakarta.inject.Provider 사용

 다음 라이브러리르 gradle에 추가

 

스프링부트 3.0 미만
javax.inject:javax.inject:1

 

스프링부트 3.0 이상
jakarta.inject:jakarta.inject-api:2.0.1

 

javax.inject.Provider 참고용 코드

• 스프링부트 3.0 미만

package javax.inject;
public interface Provider<T> {
  T get(); 
}

 

스프링 부트 3.0은 jakarta.inject.Provider 사용

@Scope("singleton")
static class ClientBean{
    @Autowired
    private Provider<PrototypeBean> prototypeBeanProvider;

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

• 실행해보면 provider.get()를 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음
• provider의 get()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함(DL)
• 자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워짐
• Provider는 지금 딱 필요한 DL 정도의 기능만 제공
• 장점 : 심플, 단점 : 심플

 

특징

• get() 메서드 하나로 기능이 매우 단순함
• 별도의 라이브러리가 필요함
• 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용 가능

 

정리

• 프로토타입 빈은 언제 사용하는가?
• 매번 사용할 때마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용

• 실무에서 웹 애플리케이션을 개발하다보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물음
• ObjectProvider, JSR330 Provider등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용 가능

 

💡 cf 1)
스프링이 제공하는 메서드에 @Lookup 애노테이션을 사용하는 방법도 있지만, 이전 방법들로 충분하고, 고려해야 할 내용도 많아서 생략하겠음

 

 

💡cf 2)
실무에서 자바 표준인 JSR-330 Provider를 사용할 것인지, 아니면 스프링이 제공하는 ObjectProvider를 사용할 것인지 고민하게 될 것임
-> ObjectProvider는 DL을 위한 편의 기능을 많이 제공해주고 스프링 이외에 별도의 의존관계 추가가 필요없기 때문에 편리함.
-> 만약 코드를 스프링이 아닌 다른 컨테이너에서도 사용할 수 있어야 한다면 JSR-330 Provider를 사용해야 함

스프링을 사용하다 보면 이 기능 뿐만 아니라 다른 기능들도 자바 표준과 스프링이 제공하는 기능이 겹칠 때가 많이 ㅇㅆ음
-> 대부분 스프링이 더 다양하고 편리한 기능을 제공해주기 때문에, 특별히 다른 컨테이너를 사용할 일이 없다면, 스프링이 제공하는 기능을 사용하면 됨

 

 

 

 

📌  웹스코프

✔ 싱글톤 : 스프링 컨테이너의 시작과 끝까지 함께하는 매우 긴 스코프
✔ 프로토타입 : 생성과 의존관계 주입, 그리고 초기화까지만 진행하는 특별한 스코프

 

⚡ 웹 스코프의 특징

• 웹 환경에서만 동작
• 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리함
  • 종료 메서드 호출됨

 

⚡ 웹 스코프 종류

• request : HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리됨
• session : HTTP Session과 동일한 생명주기를 가지는 스코프
• application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
• websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

 

 

HTTP request 요청 당 각각 할당되는 request 스코프

 

 

📌  request 스코프 예제 만들기

⚡ 웹 환경 추가

✔ 웹 스코프는 웹 환경에서만 동작하므로 web 환경이 동작하도록 라이브러리를 추가하자

 

🔶 build.gradle에 추가

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

 

-> hello.core.CoreApplication의 main 메서드를 실행하면 웹애플리케이션이 실행되는 것을 확인할 수 있음

 

Tomcat started on port(s): 8080 (http) with context path ''
Started CoreApplication in 0.914 seconds (JVM running for 1.528)

 

💡 cf 1)
spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰켓 서버를 활용해서 웹 서버와 스프링을 함께 실행시킴

 

💡 cf 2)
스프링 부트는 웹 라이브러리가 없으면 우리가 지금까지 학습한 AnnotationConfigApplicationContext을 기반으로 애플리케이션을 구동함
-> 웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로 AnnotationConfigServletWebServerApplicationContext를 기반으로 애플리케이션 구동함

 

 

✔ 만약 기본 포트인 8080 포트를 다른 곳에서 사용중이어서 오류가 발생하면 포트를 변경해야 함

• 9090포트로 변경하려면 다음 설정 추가

 

🔶 main/resources/application.properties

server.port=9090

 

 

⚡ request 스코프 예제 개발

✔ 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어려움

• request 스코프 사용해야 함

[d06b992f...] request scope bean create
[d06b992f...][http://localhost:8080/log-demo] controller test
[d06b992f...][http://localhost:8080/log-demo] service id = testId
[d06b992f...] request scope bean close

• 기대하는 공통 포맷 : [UUID][requestURL]{message}
• UUID를 사용해서 HTTP 요청을 구분하자
• requestURL 정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인하자

 

⚡ MyLogger

 

🔶  MyLogger 

package hello.core.common;


import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

import java.util.UUID;

@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(){
        String 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);
    }
}

• 로그를 출력하기 위한 MyLogger 클래스
• @Scope(value="request")를 사용해서 request 스코프로 지정함
  • 이 빈은 HTTP 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸됨
• 이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메서드를 사용해서 uuid를 생성해서 저장해둠
  • 이 빈은 HTTP 요청 당 하나씩 생성되므로, uuid를 저장해두면 다른 HTTP 요청과 구분할 수 있음
• 이 빈이 소멸되는 시점에 @PreDestroy를 사용해서 종료 메시지를 남김
• requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 setter로 입력받음

 

LogDemoController

🔶 main/.../hello.core/web/LogDemoController

package hello.core.web;

import hello.core.common.MyLogger;
import jakarta.servlet.http.HttpServletRequest;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@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";
    }
}

• 로거가 잘 작동하는지 확인하는 테스트용 컨트롤러임
• HttpServletRequest를 통해서 요청 URL을 받음
  • requestURL 값 http://localhost:8080/log-demo
• 받은 requestURL 값을 myLogger에 저장해둠
  • myLogger는 HTTP 요청 당 각각 구분되므로 다른 HTTP 요청때문에 값이 섞이는 걱정은 하지 않아도 됨
• 컨트롤러에서 controller test라는 로그를 남김

 

💡cf)
requestURL을 MyLogger에 저장하는 부분은 컨트롤러 보다는 공통 처리가 가능한 스프링 인터셉터나 서블릿 필터 같은 곳을 활용하는 것이 좋음
-> 예제를 단순화하고, 아직 스프링 인터셉터를 학습하지 않은 사람을 위해서 컨트롤러를 사용함(스프링 웹에 익숙하다면 인터셉터 사용)

 

LogDemoService 추가

 

🔶 LogDemoService

package hello.core.web;

import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    public final MyLogger myLogger;
    public void logic(String id) {
        myLogger.log("service id = "+id);
    }
}

• 비지니스 로직이 있는 서비스 계층에서도 로그를 출력해보자
  ❗ request scope를 사용하지 않고 파라미터로 이 모든 정보를 서비스 계층에 넘긴다면, 파라미터가 많아서 지저분해짐
  • 더 문제는 requestURL 같은 웹과 관련된 정보가 웹과 관련없는 서비스 계층까지 넘어가게 됨
  • 웹과 관련된 부분은 컨트롤러까지만 사용해야함
  • 서비스 계층은 웹 기술에 종속되지 않고, 가급적 순수하게 유지하는 것이 유지보수 관점에서 좋음
• request scope의 MyLogger 덕분에 이런 부분을 파라미터로 넘기지 않고, MyLogger의 멤버 변수에 저장해서 코드와 계층을 깔끔하게 유지할 수 있음

 

기대하는 출력

[d06b992f...] request scope bean create
[d06b992f...][http://localhost:8080/log-demo] controller test
[d06b992f...][http://localhost:8080/log-demo] service id = testId
[d06b992f...] request scope bean close

 

실제는 기대와 다르게 애플리케이션 실행 시점에 오류 발생

Error creating bean with name 'myLogger': Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton;

• 스프링 애플리케이션을 실행시키면 오류 발생
  • 메시지 마지막에 싱글톤이라는 단어가 나오고 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않음
  • 이 빈은 실제 고객의 요청이 와야 생성 가능

 

 

📌 스코프와 Provider

 

✔ 위에서 난 오류를 Provider를 사용하면서 해결할 수 있음

• ObjectProvider를 사용해볼 수 있음

 

🔶 LogDemoController.class 코드 수정

package hello.core.web;

import hello.core.common.MyLogger;
import jakarta.servlet.http.HttpServletRequest;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@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";
    }
}

 

 

🔶 LogDemoService 코드 수정

package hello.core.web;

import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    public final ObjectProvider<MyLogger> myLoggerProvider;
    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = "+id);
    }
}

• main() 메서드로 스프링을 실행하고, 웹 브라우저에 http://localhost:8080/log-demo를 입력

 

출력결과

[d06b992f...] request scope bean create
[d06b992f...][http://localhost:8080/log-demo] controller test
[d06b992f...][http://localhost:8080/log-demo] service id = testId
[d06b992f...] request scope bean close

• ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음
• ObjectProvider.getObject()를 호출하시는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리됨
• ObjectProvider.getObject()를 LogDemoController, LogDemoService에서 각각 한 번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환됨

 

 

📌 스코프와 프록시

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

 

❗proxyMode = ScopedProxyMode.TARGET_CLASS를 추가!!

• 적용 대상이 인터페이스가 아닌 클래스면 : TARGET_CLASS 선텍
• 적용 대상이 인터페이스면 INTERFACES 선택
  • MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있음

❗ 코드를 Provider 사용 이전으로 돌려놓고 시작

 

🔶 LogDemoController.class 코드 수정

package hello.core.web;

import hello.core.common.MyLogger;
import jakarta.servlet.http.HttpServletRequest;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@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";
    }
}

 

🔶 LogDemoService 코드 수정

package hello.core.web;

import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    public final MyLogger myLogger;
    public void logic(String id) {
        myLogger.log("service id = "+id);
    }
}

• 잘 동작함!!(Provider 사용 이전과 코드가 같은데 성공)

 

⚡ 웹 스코프와 프록시 동작 원리

System.out.println("myLogger = " + myLogger.getClass());

 

출력 결과

myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

 

CGLIB라는 라이브러리로 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입함

• @Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS를 설정하면 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성함
• 우리가 등록한 순수한 MyLogger 클래스가 아니라 MyLogger$$EnhancerBySpringCGLIB이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있음
• 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 가짜 프록시 객체 등록
• ac.getBean("myLogger", MyLogger.class)로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있음
  • 의존관계 주입도 이 가짜 프록시 객체가 주입됨

 

 

 

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

• 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고 있음
• 클라이언트가 myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것임
• 가짜 프록시 객체는 request 스코프의 진짜myLogger.logic()을 호출
• 가짜 프록시 객체는 원본 클래스를 상속받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용 가능(다형성)

 

동작 정리

• CGLIB라는 라이브러리로 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입함
• 이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있음
• 가짜 프록시 객체는 실제 request scope와는 관계 없음
  • 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤처럼 동작함

 

특징 정리

• 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있음
• 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점임
• 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있음
  • 다형성과 DI 컨테이너가 가진 큰 강점
• 꼭 웹 스코프가 아니어도 프록시는 사용할 수 있음

 

주의점

• 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 함
• 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용해야 함
  • 무분별하게 사용하면 유지보수하기 어려움

 

 

 

 

 

출처 : <인프런 스프링 핵심원리 - 기본편_김영한>을 수강하고 참고하여 작성한 글입니다.

 

 

 

---

PREV

[스프링 핵심 원리 - 기본편] 8. 빈 생명주기 콜백