[Spring] 스프링 기초 (2)

스프링 컨테이너와 스프링 빈

스프링 컨테이너 생성

ApplicationContext는 스프링 컨테이너이자 인터페이스이다. 따라서 다형성이 적용된다. AnnotationConfigApplicationContext도 있고, 다른 ApplicationContext들도 있다.

설정임을 나타내는 @Configuration이 붙은 AppConfig.class를 매개변수로 하는 AnnotationConfigApplicationContext을 생성하면, @Bean이 붙은 것들이 스프링 저장소에 저장된다. 빈 이름은 메소드 이름, 빈 객체는 return 값이다.

 

빈의 이름은 기본적으로 메소드 이름이며, 항상 다른 이름을 부여해야 한다.

 

3. 스프링 빈 의존 관계 설정

스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입한다. (서로 다른 memberRepository를 가르키는 거 아닌가..?)->@Configuration과 싱글톤 참조

 

컨테이너에 등록된 모든 빈 조회

package hello.core.beanfind;

import hello.core.AppConfig;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class ApplicationContextInfoTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력")
    void findAllBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) { // iter 치고, Tab
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + " object = " + bean);
        }
    }

    @Test
    @DisplayName("애플리케이션 빈 출력")
    void findApplicationAllBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames(); // Bean의 이름들을 다 가져옴
        for (String beanDefinitionName : beanDefinitionNames) { // iter 치고, Tab
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);   // Bean의 정보를 가져옴

            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION){ // <-> ROLE_INFRASTRUCTURE 스프링 내부에서 사용하는 빈
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName + " object = " + bean);
            }

        }
    }
}

BeanDefinition.ROLE_APPLICATION은 프로그래머가 등록한 빈이고, ROLE_INFRASTRUCTURE 스프링 내부에서 사용하는 빈이다.

 

스프링 빈 조회 - 기본

ac.getBean(이름, 타입)
ac.getBean(타입)

@Test
@DisplayName("빈 이름으로 찾기")
void findBeanByName(){
    MemberService memberService = ac.getBean("memberService", MemberService.class);
//        System.out.println("memberService = " + memberService);
//        System.out.println("memberService.getClass() = " + memberService.getClass());
    Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
}

memberService는 AppConfig에서 memberService 메소드의 return 결과인 memberServiceImpl이다.

 

@Test
@DisplayName("타입으로 찾기")
void findBeanByType(){
    MemberService memberService = ac.getBean(MemberService.class);
    Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
}

타입만으로도 찾을 수 있다.

 

@Test
@DisplayName("구체 타입으로 찾기")
void findBeanBySpecificType(){
    MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
    Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
}

구체 타입으로 찾을 수는 있지만, 역할과 구현을 분리해야 한다는 원칙에 따라 좋은 방법은 아니다. 

 

@Test
@DisplayName("빈 이름으로 찾기 실패")
void findBeanByNameX(){
    MemberService memberService = ac.getBean("fail", MemberService.class);
}

스프링 빈에 등록되지 않은 이름으로 getBean을 할 경우, 에러가 발생한다.

 

스프링 빈 조회 - 동일한 타입이 둘 이상

@Test
@DisplayName("동일 타입 존재 시 오류 발생")
void findBeanByTypeDuplicate(){
    MemberRepository memberRepository = ac.getBean(MemberRepository.class);
}

@Configuration
static class TestConfig {
    @Bean
    public MemberRepository memberRepository1(){
        return new MemoryMemberRepository();
    }

    @Bean
    public MemberRepository memberRepository2(){
        return new MemoryMemberRepository();
    }
}

동일한 타입을 갖는 빈이 여러 개일 때, getBean을 하면 오류가 발생한다.

 

@Test
@DisplayName("동일 타입 존재 시 이름을 지정하면 오류 발생하지 않음")
void findBeanByTypeDuplicate2(){
    MemberRepository memberRepository = ac.getBean("memberRepository1", MemberRepository.class);
}

이름을 지정하면 오류가 발생하지 않는다. 이로써 알 수 있는 것은 클래스가 같아도 이름이 다르면, 스프링 빈으로 등록하는 것으로 보인다.

 

@Test
@DisplayName("특정 타입을 가지는 빈을 모두 조회하기")
void findAllBeanByType(){
    Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
    for (String key : beansOfType.keySet()) {
        System.out.println("key = " + key + " value = " + beansOfType.get(key));;
    }
    System.out.println("beansOfType = " + beansOfType);
    Assertions.assertEquals(beansOfType.size(), 2);
}

beansOfType return 값의 key는 bean의 이름, value는 bean이다.

 

스프링 빈 조회 - 상속 관계가 있는 경우

부모 타입을 조회하면, 자식 타입도 조회된다.

모든 자바 객체의 최고 부모는 Object인데, Object를 조회하면 모든 스프링 빈이 조회된다.

 

@Test
@DisplayName("부모 타입으로 getBean할 시 자식이 둘 이상 있으면, 중복 오류 발생")
void findBeanByParentTypeDuplicate() {
	//DiscountPolicy bean = ac.getBean(DiscountPolicy.class);
    assertThrows(NoUniqueBeanDefinitionException.class, () ->
	ac.getBean(DiscountPolicy.class));
}

인터페이스인 DiscountPolicy의 자식이 둘 이상일 때, getBean을 하게 되면, 어느 자식을 선택해야 할지 모르므로 오류가 발생한다.

 

@Test
@DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다")
void findBeanByParentTypeBeanName() {
	DiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy",
	DiscountPolicy.class);
	assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
}

자식의 빈 이름을 지정하는 것으로 해결 가능하다.

 

@Test
@DisplayName("특정 하위 타입으로 조회")
void findBeanBySubType() {
	RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
	assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
}

자식들의 타입이 모두 다르다면, 특정 하위 타입으로 조회할 수 있다.

 

@Test
@DisplayName("부모 타입으로 모두 조회하기")
void findAllBeanByParentType() {
	Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
	assertThat(beansOfType.size()).isEqualTo(2);
	for (String key : beansOfType.keySet()) {
		System.out.println("key = " + key + " value =" +
		beansOfType.get(key));
	}
}

getBean이 아니기 때문에 오류가 발생하지 않고, 모든 빈이 나온다.

 

BeanFactory와 ApplicationContext

 

BeanFactory

• 스프링 컨테이너의 최상위 인터페이스다.
• 스프링 빈을 관리하고 조회하는 역할을 담당한다.
• getBean() 을 제공한다.
• 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다.

 

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공한다.
빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 왜 필요하지?
애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요하다.

 

메시지소스를 활용한 국제화 기능
예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력

 

환경변수
로컬, 개발, 운영등을 구분해서 처리

 

애플리케이션 이벤트
이벤트를 발행하고 구독하는 모델을 편리하게 지원

 

편리한 리소스 조회
파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

 

결론적으로, BeanFactory와 다른 인터페이스를 상속받는 ApplicationContext를 사용한다.

 

다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받을 수 있다.

요즘은 AnnotationConfigApplicationContext를 많이 사용한다.

 

xml로 설정하기

package hello.core.xml;

import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.GenericXmlApplicationContext;

public class XmlAppContext {
    @Test
    void xmlAppContext(){
        ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

설정정보를 Xml로부터 얻는 ApplicationContext

 

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="memberService" class="hello.core.member.MemberServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
    </bean>
    <bean id="memberRepository"
          class="hello.core.member.MemoryMemberRepository" />
    <bean id="orderService" class="hello.core.order.OrderServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
        <constructor-arg name="discountPolicy" ref="discountPolicy" />
    </bean>
    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy" />
</beans>

orderService라는 빈은 OrderServiceImpl 생성자를 반환하고, memberRepository와 discountPolicy를 전달받는다.

• id : 스프링 빈 이름
• class : 스프링 빈 value
• contructor-arg : name은 매개변수 이름, ref는 참조할 id

 

스프링 빈 설정 메타 정보 - BeanDefinition

스프링이 다양한 형식으로 설정할 수 있는 이유는 BeanDefinition이라는 추상화가 있기 때문이다. 스프링 컨테이너는 빈 설정 메타정보인 BeanDefinition만 알면 된다. 

 

AnnotationConfigApplicationContext 는 AnnotatedBeanDefinitionReader 를 이용하여 AppConfig.class 를 읽고 BeanDefinition 을 생성한다.

GenericXmlApplicationContext 는 XmlBeanDefinitionReader 를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition 을 생성한다.

 

싱글톤 컨테이너

웹 애플리케이션과 싱글톤

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 

 

package hello.core.singleton;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class SingletonTest {

    @Test
    @DisplayName("스프링을 사용하지 않은 DI 컨테이너")
    void pureContainer(){
        AppConfig appConfig = new AppConfig();
        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    }
}

 

스프링을 사용하지 않으면(= @Bean으로 등록하고, getBean으로 가져오지 않으면), memberService를 불러올 때마다 새로운 객체가 생성된다. 

해결하는 방법은 하나만 생성하고, 그것을 공유하도록 설계하는 것이다. 이것이 싱글톤이다.

 

싱글톤 패턴

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

private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하여 생성하지 못하도록 막아야 한다.

package hello.core.singleton;

public class SingletonService {
    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance(){
        return instance;
    }

    private SingletonService(){
        
    }
    
    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

객체를 static 영역에 미리 생성해놓는다.

 

객체를 접근할 수 있는 방법은 getInstance()를 통해서만 가능하다.

 

함부로 접근하지 못하도록 private로 막아두었다.

 

위 방법은 싱글톤 패턴을 구현하는 여러가지 방법 중 가장 단순하고 안전한 방법이다.

 

@Test
@DisplayName("싱글톤 패톤을 적용한 객체 사용")
void singletonServiceTest(){
    SingletonService singletonService1 = SingletonService.getInstance();
    SingletonService singletonService2 = SingletonService.getInstance();

    System.out.println("singletonService1 = " + singletonService1);
    System.out.println("singletonService2 = " + singletonService2);

    Assertions.assertThat(singletonService1).isSameAs(singletonService2);
}

하나의 객체만을 가르키므로, singletonService1과 singletonService2는 같다.

equalTo는 값이 같은지, sameAs는 참조가 같은지 비교한다.

 

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드가 많이 들어간다.
• 싱글톤 패턴을 사용할 때 구체 클래스에 의존해서 DIP(의존 역전 원칙)을 위반한다. (AppConfig에 구체화가 들어감)
• OCP를 위반할 가능성도 높아지게 된다.
• 테스트하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

참고) DIP : 추상화에 의존해야지, 구체화에 의존하면 안 된다

 

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제를 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다. 스프링 빈은 싱글톤으로 관리되는 빈이다.

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    MemberService memberService1 = ac.getBean("memberService", MemberService.class);
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);
    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);

    Assertions.assertThat(memberService1).isSameAs(memberService2);
}

스프링 빈은 싱글톤으로 관리되기 때문에 singletonService1과 singletonService2는 같다.

 

싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링의 싱글톤 컨테이너든 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 상태를 유지하게 설계하면 안된다. 즉, 값을 저장하거나 수정할 수 없게 해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

package hello.core.singleton;

public class StatefulService {
	private int price; // 상태 저장
    
    public void order(String name, int price) {
		System.out.println("name = " + name + " price = " + price);
		this.price = price; // 상태 변경
	}

	public int getPrice() {
    	return price;
	}
}

package hello.core.singleton;

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.Bean;

import static org.junit.jupiter.api.Assertions.*;

class StatefulServiceTest {
    @Test
    void statefulServiceSingleton(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        statefulService1.order("userA", 10000);
        statefulService2.order("userB", 20000);

        int price = statefulService1.getPrice();

        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

    static class TestConfig {
        @Bean
        public StatefulService statefulService(){
            return new StatefulService();
        }
    }
}

스프링에 의해 statefulService라는 싱글톤 컨테이너를 사용한다. A가 10000원 짜리 주문을 하고, B가 20000원 짜리 주문을 한 후에 A가 주문한 가격을 조회하면, 의도와 다르게 20000원이 도출된다. 싱글톤 컨테이너를 사용하고, 중간에 값을 수정하는 과정이 있기 때문에 발생되는 문제이다.

 

★ ★ ★ 스프링은 빈은 무상태로 설계하자! ★ ★ ★

package hello.core.singleton;

public class StatelessService {
    public void order(String name, int price){
        System.out.println("name = " + name + " price " + price);
        return price;
    }
}

@Test
void statefulServiceSingleton(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
    StatefulService statefulService1 = ac.getBean(StatefulService.class);
    StatefulService statefulService2 = ac.getBean(StatefulService.class);

    int userAPrice = statefulService1.order("userA", 10000);
    int userBPrice = statefulService2.order("userB", 20000);

    Assertions.assertThat(userAPrice).isEqualTo(10000);
}

값을 수정할 수 없게 하고, 필드 대신에 자바에서 공유되지 않는 지역변수를 이용한 결과이다.

 

@Configuration과 싱글톤

AppConfig의 memberService와 orderService를 호출하면, 서로 다른 MemoryMemberRepository가 생성되는 것처럼 보인다.

public class ConfigurationSingletonTest {
    @Test
    @DisplayName("두 개가 같아야 함")
    void configurationTest(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberRepository1 = " + memberRepository1);
        System.out.println("memberRepository2 = " + memberRepository2);

        Assertions.assertThat(memberRepository1).isSameAs(memberRepository2);
    }
}

확인 결과 둘은 같다. 

 

★★ getMemberRepository를 인터페이스인 MemberService에는 선언하지 않았으므로, 사용하지 못한다.

 

@Configuration과 바이트코드 조작의 마법

@Test
void configurationDeep(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = ac.getBean(AppConfig.class);
    System.out.println("bean.getClass() = " + bean.getClass());
}

AppConfig에서 끝나지 않고, $$SpringCGLIB~ 라는 것이 붙는다.

 appConfig 빈에는 AppConfig를 상속받아 조작한 AppConfig@CGLIB가 등록되어 있다.

 

@Configuration이 없어도 스프링 빈으로 등록은 되지만, 싱글톤이 깨진다. 그래서 쓰는 것이 좋다.

 

컴포넌트 스캔

컴포넌트 스캔과 의존관계 자동 주입

스프링 빈을 등록할 때는 @Bean이나 XML의 <bean>을 톻해서 등록할 수 있다.

하지만, 등록할 스프링 빈이 많아지면, 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다.

그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈으로 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 

 

package hello.core;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

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

}

@Configuration -> 설정 관련 클래스로 만든다. @Configuration 내부에 @Component가 포함되므로, 이것이 붙은 클래스도 스프링 빈으로 등록된다.

@ComponentScan -> 클래스가 ComponentScan을 가능하게 하는데, Filter를 이용하면 다른 Configuration이 포함되지 않도록 제외시킨다.

 

스프링 빈으로 등록할 클래스 위에 @Component를 붙이고, 의존성 주입이 필요한 곳에 @Autowired를 붙인다.

package hello.core.scan;

import hello.core.AutoAppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class AutoAppConfigTest {
    @Test
    void basicScan(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);

        MemberService memberService = ac.getBean(MemberService.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

 

@ComponentScan 은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록한다.

이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.
예를 들어, 기본적으로 MemberServiceImpl 클래스라면 memberServiceImpl로 저장된다.

만약 스프링 빈의 이름을 직접 지정하고 싶으면, @Component("memberService2")처럼 이름을 부여하면 된다.

 

생성자에 @Autowired를 지정하면, 스프링 컨테이너가 기본적으로 타입이 같은(자식 포함) 스프링 빈을 찾아서 주입한다.

 

 

탐색 위치와 기본 스캔 대상

package hello.core;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

@Configuration
@ComponentScan(
        basePackages = "hello.core.member",
        excludeFilters = @ComponentScan.Filter(type= FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {

}

basePackages는 탐색할 패키지의 시작 위치를 지정하는데, 이 위치부터 하위 패키지를 모두 탐색한다. 위와 같이 지정해준다면, order와 discount 관련 스프링 빈은 생성되지 않는다.

 

backPackages를 지정하지 않으면, @ComponentScan이 붙은 설정 정보 클래스가 있는 패키지가 시작 위치가 된다.

 

★관례적으로, 설정 정보 클래스를 프로젝트 최상단에 두는 것이 좋다. @SpringBootApplication은 @ComponentScan을 포함하므로, 이를 포함하는 파일은 프로젝트 최상단에 둔다.

 

컴포넌트 스캔 기본 대상

@Component : 컴포넌트 스캔의 대상이고, 스프링 빈으로 등록됨.

@Controller : 스프링 MVC 컨트롤러에서 사용

@Service : 스프링 비즈니스 로직에서 사용, 데이터 계층의 예외를 스프링 예외로 변환해준다.(아직은 모르겠다)

@Repository : 스프링 데이터 접근 계층에서 사용

@Configuration : 스프링 설정 정보에서 사용, @Bean이 붙어있어 등록되는 스프링 빈이 싱글톤을 유지하도록 추가 처리

 

참고) 사실 애노테이션에는 상속관계라는 것이 없다. 애노테이션이 특정 애노테이션을 포함하는 것을 인식할 수 있는 것은 자바 언어가 지원하는 기능은 아니고, 스프링이 지원하는 기능이다.

 

필터 (중요도 낮음)

includeFilters : 컴포넌트 스캔 대상을 추가로 지정, @Component라고 붙은 것 이외에 추가로 스캔할 것

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

 

package hello.core.scan.filter;

import java.lang.annotation.*;

@Target({ElementType.TYPE}) // 클래스 레벨에 붙는다는 뜻
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {

}

package hello.core.scan.filter;

import java.lang.annotation.*;

@Target({ElementType.TYPE}) // 클래스 레벨에 붙는다는 뜻
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {

}

포함할 애노테이션과 포함하지 않을 애노테이션을 각각 하나씩 만든다.

 

package hello.core.scan.filter;

@MyIncludeComponent
public class beanA {
}

package hello.core.scan.filter;

@MyExcludeComponent
public class beanB {
}

 

package hello.core.scan.filter;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

public class ComponentFilterAppConfigTest {
    @Test
    void filterScan(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
        BeanA beanA = ac.getBean(BeanA.class);
        Assertions.assertThat(beanA).isNotNull();

        org.junit.jupiter.api.Assertions.assertThrows(NoSuchBeanDefinitionException.class, ()->ac.getBean(BeanB.class));
    }


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

    }
}

beanA는 스프링 빈으로 등록되어 getBean할 수 있지만, beanB는 등록될 수 없으므로 getBean할시 오류가 발생한다.

 

FilterType Option

ANNOTATION : 기본값, 애노테이션을 인식해서 동작한다.
ex) org.example.SomeAnnotation
ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.
ex) org.example.SomeClass
ASPECTJ: AspectJ 패턴 사용
ex) org.example..*Service+
REGEX: 정규 표현식
ex) org\.example\.Default.*
CUSTOM: `TypeFilter` 이라는 인터페이스를 구현해서 처리
ex) org.example.MyTypeFilter

 

참고) @Component 면 충분하기 때문에, includeFilters 를 사용할 일은 거의 없다고 한다. excludeFilters는 여러가지 이유로 간혹 사용할 때가 있지만 많지는 않다.

특히, 최근 스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데, 개인적으로는 옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장하신다고 한다.

 

중복 등록과 충돌

1. 자동 빈 등록 vs 자동 빈 등록 -> 충돌 오류

2. 수동 빈 등록 vs 자동 빈 등록 -> 수동 빈 우선, 하지만  최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다. (@SpringBootApplication으로 실행할 때)

 

의존 관계 자동 주입

의존관계 주입 방법

생성자 주입

생성자를 통해서 의존 관계를 주입하는 방법이다.

 

★불변★ 이 중요한데, 생성자 호출시점에 매개변수들이 딱 1번만 호출되는 것이 보장된다. 즉, 주입되는 시점을 제외하고는 다른 것으로 주입할 수 없다는 의미이다.

 

final이 붙으면 생성자 실행이 완료될 때까지 무조건 지정되어 있어야 하고, 생성자 실행이 완료되면 변경할 수 없다. 생상자 주입을 통해서 생성자 실행 과정에서 파라미터 생성자가 주입되어 지정된다. 다른 주입 방식들은 생성자 실행 이후에 일어나는 것이므로, final을 이용할 수 없다. final과 생성자 주입 방식을 사용하여 누락을 방지할 수 있다는 장점이 있다.

 

생성자가 하나이면, @Autowired가 안붙어도 의존 관계 주입이 일어난다.

 

옵션 처리

package hello.core.autowired;

import hello.core.member.Member;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.lang.Nullable;

import java.util.Optional;

public class AutowiredTest {

    @Test
    void AutowiredOption(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutowiredConfig.class);
    }

    @Configuration
    static class AutowiredConfig {
        @Autowired(required = false)
        public void setNoBean1(Member member) {
            System.out.println("setNoBean1 = " + member);
        }

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

        @Autowired
        public void setNoBean3(Optional<Member> member){
            System.out.println("setNoBean3 = " + member);
        }
    }
}

@Autowired에서 required 옵션의 기본값이 true로 되어 있어서 주입할 것을 불러올 수 없으면, 오류가 발생한다. required 옵션이 false이고, 주입할 수 있는 것이 없으면 수정자 메서드 자체가 호출되지 않는다.

@Nullable : 자동 주입할 대상이 없으면, null이 입력된다.

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

 

롬복과 최신 트렌드

롬복을 사용하기 위해서 필요한 설정

//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'
	}
}

build.gradle에 위 코드를 추가하고, plugin에서 lombok 설치하고, Annotation Processors에서 Enable annotation processing 체크하면 롬복을 사용할 수 있다.

 

롬복의 간단한 사용

package hello.core;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@Getter
@Setter
@ToString
public class HelloLombok {
    private int age;
    private String name;

    public static void main(String[] args) {
        HelloLombok helloLombok = new HelloLombok();
        helloLombok.setName("신짱구");

        System.out.println("name = " + helloLombok.getName());
        System.out.println(helloLombok);
    }
}

@Getter, @Setter를 붙이는 것만으로도 Getter, Setter가 구현된다.

 

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

@RequiredArgsConstructor를 클래스 위에 붙여주는 것만으로 위 생성자 코드를 대체할 수 있다. Ctrl + F12를 누르면 생성자를 확인할 수 있다.

 

@Autowired 필드 명, @Qualifier, @Primary

주입할 수 있는 빈이 2개 이상 -> 문제 발생!

FixedDiscountPolicy와 RateDiscountPolicy 모두 @Component를 추가하면 에러가 발생한다.

 

@Autowired 매칭

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

@Autowired
private DiscountPolicy rateDiscountPolicy;

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

위는 필드(클래스 내부 멤버) 이름 매칭, 아래는 파라미터 이름 매칭으로 모두 Test를 통과한다. -> 이름을 보고 매칭한다.

 

@Qualifier

실제 빈 이름을 변경하는 것이 아니라, 별명을 추가한다. @Qualifier 끼리 매칭하고, 없으면 빈에서 찾고, 그것도 안되면 예외가 발생한다.

 

같은 부모를 가지는 클래스 중 하나에  @Qualifier("mainDiscountPolicy")를 붙이면,  @Qualifier("mainDiscountPolicy")가 붙은 자식 클래스를 사용한다.

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.stereotype.Component;

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy{
    double discountRate = 0.1;

    @Override
    public int discount(Member member, int price) {
        if (member.getGrade() == Grade.VIP){
            return (int)(price * discountRate);
        }
        else{
            return 0;
        }
    }
}

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

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

@Qualifier는 @Qualifier를 찾는 용도로만 사용하자!!

 

@Primary

우선순위를 지정한다. @Component를 다 붙여놓고, @Primary를 붙이면 매우 편할 듯하다.

 

우선 순위

@Primary는 FixedDiscountPolicy에, @Qualifier는 RateDiscountPolicy에 붙어있고, @Qualifier를 사용한다면, 자세한 정보를 제공하는 @Qualifier가 우선된다.

 

애노테이션 직접 만들기

@Qualifier("mainDiscountPolicy") 내부의 문자열은 컴파일 시간에 검증되지 않는다. 따라서, 문자열을 mainnDiscountPolicy라고 잘못 써도 컴파일 시간에 알 수 없다. 이를 방지하기 위해 애노테이션을 직접 만들어서 그 안에 @Qualifier를 넣어서 사용하는 방법이 있다.

package hello.core.annotation;

import org.springframework.beans.factory.annotation.Qualifier;

import java.lang.annotation.*;

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

애노테이션을 만들고, 

package hello.core.order;

import hello.core.annotation.MainDiscountPolicy;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.*;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

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

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

    ...
}

만든 애노테이션을 붙인다.

 

조회한 빈이 모두 필요할 때, List, Map

클라이언트가 할인의 종류를 선택할 수 있는 경우에 DiscountService에서는 Policy들을 모두 가져와야 한다.

package hello.core.autowired;

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
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 java.util.List;
import java.util.Map;

public class AllBeanTest {
    @Test
    void findAllBean(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int fixDiscountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
        Assertions.assertThat(fixDiscountPrice).isEqualTo(1000);

        int rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");
        Assertions.assertThat(rateDiscountPrice).isEqualTo(2000);

    }

    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        @Autowired
        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);
            return discountPolicy.discount(member, price);
        }
    }
}

AutoAppConfig와 DiscountService가 스프링 빈에 등록된다.

 

★AutoAppConfig에 @ComponentScan이 있으므로, DiscountPolicy들을 스프링 빈에 등록한다!

 

Map과 List에 자동으로 주입이 일어나고, DiscountPolicy들이 담겨 있다.

 

discount에서 전달받은 discountCode를 key로 사용하여 인스턴스를 얻는다.

 

자동, 수동의 올바른 실무 운영 기준

편리한 자동 기능(컴포넌트 스캔과 자동 주입)을 기본으로 사용하자!

 

편리한 자동 기능을 기본으로 사용하자
직접 등록하는 기술 지원 객체(AOP, 데이터베이스 연결..)는 수동 등록
다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

 

빈 생명주기 콜백

빈 생명주기 콜백 시작

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션
종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

package hello.core.lifecycle;

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메세지");
    }

    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);
    }
}

package hello.core.lifecycle;

import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

public class BeanLifeCycleTest {

    @Test
    public void lifeCycleTest(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean
        public NetworkClient networkClient(){
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://naver.com");
            return networkClient;
        }
    }
}

스프링 빈으로 등록하는 과정에서 생성자를 호출할 때, url을 전달하지 않았으므로, url은 당연히 null이 된다.

 

스프링 빈의 이벤트 라이프사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입(생성자 주입은 이외의 주입)-> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
소멸전 콜백: 빈이 소멸되기 직전에 호출

 

인터페이스 InitializingBean, DisposableBean (지금은 거의 사용하지 않음)

package hello.core.lifecycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

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

afterPropertiesSet은 setter가 끝난 후에 실행된다. destroy는 스프링 컨테이너의 종료가 호출될 때 실행된다.

 

초기화, 소멸 인터페이스 단점

이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
초기화, 소멸 메서드의 이름을 변경할 수 없다.
내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

package hello.core.lifecycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class NetworkClient{
    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);
    }

    public void init(){
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메세지");
    }

    public void close(){
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

@Configuration
static class LifeCycleConfig {

    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient(){
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://naver.com");
        return networkClient;
    }
}

 

설정 정보 사용 특징

• 메서드 이름을 자유롭게 줄 수 있다.
• 스프링 빈으로 등록되는 클래스가 스프링 코드에 의존하지 않는다.
• 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적
  용할 수 있다.
• @Bean으로 등록할 때만 발생한다.

 

종료 메서드 추론

@Bean의 destroyMethod 속성에는 아주 특별한 기능이 있다.

• 라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
• @Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.
• 이 추론 기능은 close, shutdown 라는 이름의 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다. 따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다.
• 추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정하면 된다.

 

애노테이션 @PostConstruct, @PreDestroy ★★★

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

@PreDestroy
public void close(){
    System.out.println("NetworkClient.close");
    disconnect();
}

 

@PostConstruct, @PreDestroy 애노테이션 특징

• 최신 스프링에서 가장 권장하는 방법이다.
• 애노테이션 하나만 붙이면 되므로 매우 편리하다.
• 스프링에 종속적인 기술이 아니라 자바 표준이다. 따라서, 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.
• 컴포넌트 스캔과 잘 어울린다.
• 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면
  @Bean의 기능을 사용하자.

 

빈 스코프

스프링 빈은 기본적으로 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다. 이는 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 빈이 스프링 컨테이너에 존재할 수 있는 지속 시간이다.

 

스코프 종류

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

대부분은 싱글톤 빈을 사용한다.

 

프로토타입 스코프

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스 스프링 빈을 반환한다. 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

클라이언트 A가 프로토타입 빈을 요청하면, 스프링 컨테이너는 프로토타입 빈을 의존관계 주입하여 생성하고, 클라이언트 A에게 제공하고 버려버린다. 즉 컨테이너가 더 이상 관리하지 않는다. 그래서 스프링 컨테이너가 스프링 빈이 사라질 때 호출하는 @PreDestroy가 적용되지 않는다.

 

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;

public class PrototypeTest {

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

        prototypeBean prototypeBean1 = ac.getBean(prototypeBean.class);
        prototypeBean prototypeBean2 = ac.getBean(prototypeBean.class);
        System.out.println("prototypeBean1 = " + prototypeBean1);
        System.out.println("prototypeBean2 = " + prototypeBean2);
        Assertions.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");
        }
    }
}

@PreDestroy로 지정한 detroy가 실행되지 않은 것을 볼 수 있다.

 

싱글톤 빈과 프로토타입 빈을 함께 사용시 문제점

싱글톤 빈이 프로토타입 빈을 주입받아서 사용하는 경우, 결과적으로 같은 프로토타입을 이용하기 때문에 문제가 발생한다.

 

이를 해결하는 가장 간단한 해결방법은 싱글톤 빈 안에서 프로토타입 빈을 새로 요청하고 받아서 사용하는 것이다.

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;

public class PrototypeProviderTest {
    @Test
    void providerTest() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);
        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        Assertions.assertThat(count1).isEqualTo(1);
        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        Assertions.assertThat(count2).isEqualTo(1);
    }

    static class ClientBean {
        private ApplicationContext ac;  // 스프링 컨테이너 생성

        public ClientBean(ApplicationContext ac) {	// 스프링 컨테이너 주입
            this.ac = 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");
        }
    }
}

ClientBean에 PrototypeBean을 의존성 주입(DI)하지 않고, ClientBean 내부에서 PrototypeBean을 찾아서 사용하는 것을 의존성 탐색, DL(Dependency Lookup)이라고 한다. 하지만, 복잡해지는 문제가 발생한다.

 

ObjectProvider, ObjectFactory

static class ClientBean {
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

    public ClientBean(ObjectProvider<PrototypeBean> prototypeBeanProvider) {
        this.prototypeBeanProvider = prototypeBeanProvider;
    }

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

ObjectProvider는 스프링 컨테이너에서 스프링 빈을 요청해서 받아주는 대리자 역할을 한다. 프로토타입을 위해서만 사용하는 것은 아니다.

 

ObjectProvider<PrototypeBean>이므로, getObject()를 하게 되면 프로토타입을 찾는데, 스프링 컨테이너는 프로토타입에 대한 요청이 들어왔을 때, 프로토타입을 새로 생성해서 제공한다.

 

ObjectProvider는 스프링이 만들어서 제공해준다. 깔끔하게 DL 기능만 제공한다.

 

JSR330 Provider

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

    public ClientBean(Provider<PrototypeBean> prototypeBeanProvider) {
        this.prototypeBeanProvider = prototypeBeanProvider;
    }

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

ObjectProvider 대신 자바에서 제공하는 Provider가 있다.

 

프로토타입 빈은 매번 사용할 때마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 하지만, 프로토타입 자체를 실무에서는 별로 사용하는 일이 드물다고 한다.

ObjectProvider와 JSR330 Provider는 프로토타입 뿐만 아니라 다른 것에서도 사용할 수 있다.

 

웹 스코프

웹 스코프는 웹 환경에서만 동작한다.

 

웹 스코프의 종류

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

HTTP 요청이 같으면, 같은 스프링 빈을 이용한다!

 

request 스코프 예제 개발

동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다. 이럴 때 request 스코프를 사용한다.

기대하는 공통 포멧: [UUID][requestURL] {message} -> requestURL을 호출하면 message 실행
UUID를 사용해서 HTTP 요청을 구분하자.
requestURL 정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인하자.

 

참고) UUID = Universally Unique Identifier

 

MyLogger

package hello.core.common;

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

import java.util.UUID;

@Component
@Scope("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);
    }
}

 Request 요청이 오면 생성되는 스프링 빈이다.

 

Controller

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

log-demo로 Request가 있다면, HttpServletRequest로 전달받고, mylogger에 요청받은 URL을 설정한다.

 

참고) HttpServletRequest : HTTP 프로토콜의 Request 정보를 서블릿에게 전달하기 위해 사용한다.

Servlet : 웹 페이지를 만들 때 사용되는 자바 기반의 웹 애플리케이션 프로그래밍 기술

 

Service

package hello.core.web;

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

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final MyLogger myLogger;

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

하지만, 현재 문제는 Request가 없는데, MyLogger의 scope는 request이므로, Controller와 Service에 주입할 수 없어 오류가 발생한다!!

 

해결

@Controller
@RequiredArgsConstructor
public class LogDemoController {
	
    ...
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request){
        MyLogger myLogger = myLoggerProvider.getObject();
        ...
    }
}

@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를 이용하여 해결했지만, 더 간단히 하고 싶다...

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

가짜 프록시 객체를 주입해준다. 그리고 실제로 사용하는 시점에 진짜 객체를 찾아서 바꿔치기 한 후 기능을 수행한다.

가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 진짜 객체와 동일하게 사용할 수 있다.

 

Provider와 프록시의 공통점은 진짜 객체 조회를 꼭 필요한 시점까지 지연처리한다는 점이다.

 

싱글톤이 아닌 특별한 scope는 필요한 곳에서만 사용하자.