TIL

섹션 6. 자동 구성 기반 애플리케이션

메타 애노테이션과 합성 애노테이션

메타 애노테이션

• 애노테이션 위의 애노테이션
• @Component
  • @Controller
  • @Service
  • …
• 메타 애노테이션 활용의 장점
  • 스프링부트가 컴포넌트 스캔으로 읽어 들이는거나 다른 기능적으로는 차이가 없다.
  • 하지만 다른 이름을 부여함으로써 이 클래스의 의미를 더 잘 이해할 수 있다.
    • 비즈니스 로직을 담당하는군
    • 웹 요청을 받는 책임을 갖는군
  • 애노테이션 기능을 더 확장해서 추가적인 기능을 넣을 수도 있다.
• Junit에서 @Test와 비슷한 기능을 하는 애노테이션 만들어보는 예제다.

@Retention(RetentionPolicy.RUNTIME) // 런타임에 필요
@Target(ElementType.METHOD) // 메소드에 적용 가능
@Test
@interface UnitTest {
}

public class HelloServiceTest {
  
  @UnitTest
  void simpleHelloService() {
    // ...
  }
}

합성 애노테이션

• 메타 애노테이션을 하나 이상 연결해서 만드는 애노테이션을 Composed Annotation이라 한다.
  • 적용된 메타 애노테이션이 모두 적용된 효과를 낸다.

• ex) @RestController = @Controller + @ResponseBody

• 기존 @Configuration + @ComponentScan으로 동작시켰던 애플리케이션도 합성 애노테이션으로 조합할 수 있다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Configuration
@ComponentScan
public @interface MySpringbootAnnotation {
}

@MySpringbootAnnotation
public class HellobootApplication {
  //...
}

빈 오브젝트와 역할과 구분

• 애플리케이션 빈 - 개발자가 어떤 빈을 사용하겠다고 명시적으로 구성 정보를 제공한 것
  • 애플리케이션 로직 빈 - 비즈니스 로직, 도메인 로직 등
    • HelloController
    • SimpleHelloService
  • 애플리케이션 인프라스트럭처 빈 - 기술과 관련된 것들로 직접 작성하진 않고 빈 구성 정보를 통해 구성할 수 있다.
    • DataSource
    • JpaEntityManagerFactory
    • JdbcTransactionManager
  • …
• 컨테이너 인프라 스트럭처 빈 - 스프링 컨테이너 자신이거나 컨테이너가 기능을 확장하면서 추가적으로 빈으로 등록시킨 것
  • ApplicationContext/BeanFactory
  • Environment
  • BeanPostProcessor
  • BeanFactoryPostProcessor
  • DefaultAdvisorAutoProxyCreator
  • …
• 스프링 컨테이너가 수행하는 중요한 역할
  • 빈 오브젝트를 생성, 초기화
  • 빈 간의 관계를 맺고 라이프사이클을 관리

사용자 구성 정보와 자동 구성 정보

• 사용자 구성 정보
  • @ComponentScan을 통해 자동으로 자바 코드와 어노테이션에서 구성 정보를 읽어서 빈을 등록한다.
  • 사용자 로직 빈이 등록되는 방식이다.
• 자동 구성 정보
  • AutoConfiguration 메커니즘
  • 애플리케이션에서 사용되는 인프라스트럭처 빈들을 담은 @Configuration 클래스들이 있고 스프링부트가 필요한 구성을 찾아 자동 적용한다는 것이 기본 동작 원리이다.

인프라 빈 구성 정보의 분리

• 스프링부트는 주로 기술 기반의 인프라 빈을 자동 구성이라는 원리를 통해 등록을 해준다.
• 아래 두 빈은 인프라 빈이기 때문에 비즈니스 로직을 개발하는 개발자가 신경쓰지 않아도 자동으로 등록될 필요가 있다.
  • 컴포넌트 스캔 범위인 base package 밖으로 이동해도 빈으로 등록될 필요가 있다.
    • 사용자 구성 정보와 자동 구성 정보를 분리하고 싶기 때문
  • 지금 상태에선 빈으로 등록되지 않는다.

/*
main
  - java
    - tobyspring 
      - config (자동 구성 정보)
        - TomcatWebServerConfig.java
        - DispatcherServletConfig.java
    - helloboot (컴포넌트 스캔 범위, 사용자 구성 정보)
      - MySpringBootApplication.java
*/

@Configuration
public class TomcatWebServerConfig {
  @Bean
  public ServletWebServerFactory servrWebServerFactory() {
    return new TomcatServletWebServerFactory();
  }
}

@Configuration
public class DispatcherServletConfig {
  @Bean
  public DispatcherServlet dispatcherServlet() {
    return DispatcherServlet();
  }
}

• @MySpringApplicationApplication 어노테이션에 다음 설정을 추가하면 된다.
  • 그럼 빈이 잘 띄어지고 애플리케이션도 잘 실행된다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import({ // 추가
  DispatcherServletConfig.class, 
  TomcatWebServerConfig.class
})
public @interface MySpringbootApplication {
}

• 두 구성정보를 EnableMyAutoConfiguration 설정 클래스로 합쳐보자
  • 스프링부트에서 많이 본 설정 클래스 이름과 비슷할 것이다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import({
  DispatcherServletConfig.class, 
  TomcatWebServerConfig.class
})
public @interface EnableMyAutoConfiguration {
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@EnableMyAutoConfiguration
public @interface MySpringbootApplication {
}

동적인 자동 구성 정보 등록

• EnableMyAutoConfiguration을 만들 때 인프라 빈을 수동으로 Import했다.
• 동적으로 인프라 빈을 등록시키는 메커니즘이 필요하다.
• ImportSelecter 인터페이스를 사용할 수 있다.

public interface ImportSelecter {
  String[] selectImports(AnnotationMetadata importingClassMetadata);
  
  @Nullable
  default Predicate<String> getExclusionFilter() { return null; }
}

• ImportSelecter를 확장한 DefaultImportSelecter를 사용하면 Configuration이 붙은 클래스를 동적으로 등록할 수 있다.

public class MyAutoConfigImportSelecter implements DefaultImportSelecter {
  @Override
  public String[] selectImports(AnnotationMetadata importingClassMetadata) {
    return new Strint[] {
      "tobyspring.config.autoconfig.DispatcherServletConfig",
      "tobyspring.config.autoconfig.TomcatWebServerConfig"
    };
  }
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import(MyAutoConfigImportSelecter.class)
public @interface EnableMyAutoConfiguration {
}

자동 구성 정보 파일 분리

• 인프라 빈 구성 정보를 코드의 문자열이 아닌 외부 파일로 분리해서 읽어오도록 변경할 수 있다.
• 우선 MyAutoConfiguration이라는 메타 어노테이션을 만든다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Configuration
public @interface MyAutoConfiguration {
}

• MyAutoConfigImportSelecter를 아래와 같이 수정한다.

public class MyAutoConfigImportSelecter implements DefaultImportSelecter {
  private final ClassLoader classLoader;
  
  public MyAutoConfigImportSelecter(ClassLoader classLoader) {
    this.classLoader = classLoader;
  }

  @Override
  public String[] selectImports(AnnotationMetadata importingClassMetadata) {
    List<String> autoConfigs = new ArrayList<>();
    
    ImportCandidates.load(MyAutoConfiguration.class, classLoader)
      .forEach(autoConfigs::add);
    
    return autoConfigs.toArray(new String[]);
  }
}

• ImportCandidates.load()
  • resources 디릭터리 하위의 META-INF/spring/ 경로 밑에 {full-qualified-annotation-name}.imports 파일에서 클래스 정보를 읽어온다.

resources
  - META-INF.spring
    - tobyspring.config.MyAutoConfiguration.imports

• tobyspring.config.MyAutoConfiguration.imports 파일 내부에 인프라 빈 정보를 작성한다.

tobyspring.config.autoconfig.DispatcherServletConfig
tobyspring.config.autoconfig.TomcatWebServerConfig

• 이렇게 하면 ImportCandidates.load 메서드는 MyAutoConfiguration 네이밍이 된 파일에서 빈 정보를 찾는다.

자동 구성 애노테이션 적용

• 기존 DispatcherServletConfig와 TomcatWebServerConfig에 적용되어 있던 @Configuration을 @MyAutoConfiguration으로 변경한다.
  • 이렇게 하지 않아도 스프링부트는 동작한다.
  • 하지만 MyAutoConfiguration.imports 파일에서 읽어오는 정보라는 것을 명시하는 관례다.

@MyAutoConfiguration
public class TomcatWebServerConfig {
  @Bean
  public ServletWebServerFactory servrWebServerFactory() {
    return new TomcatServletWebServerFactory();
  }
}

@MyAutoConfiguration
public class DispatcherServletConfig {
  @Bean
  public DispatcherServlet dispatcherServlet() {
    return DispatcherServlet();
  }
}

• 그리고 @MyAutoConfiguration 내부 @Configuration의 엘리먼트를 하나 변경한다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Configuration(proxyBeanMethods = false) // 변경, 기본값은 true
public @interface MyAutoConfiguration {
}

@Configuration과 proxyBeanMethods

• @Configuration을 학습하기 위해 학습 테스트를 만들어보겠다
  • Bean1과 Bean2가 Common이라는 같은 빈을 의존하는 상황이라 가정

@Configuration
static class MyConfig {
  @Bean
  Common common() {
    return new Common();
  }
  
  @Bean
  Bean1 bean1() {
    return new Bean1(common());
  }
  
    @Bean
  Bean1 bean2() {
    return new Bean2(common());
  }
}

• 위 코드를 직관적으로 생각해보면 Bean1과 Bean2는 다른 common 인스턴스를 의존할 것이다.

@Test
void configuration() {
  MyConfig myConfig = new MyConfig();
  
  Bean1 bean1 = myConfig.bean1();
  Bean2 bean2 = myConfig.bean2();
  
  assertThat(bean1.common).isSamdAs(bean2.common) // 실패
}

• 그런데 MyConfig가 스프링 컨테이너의 구성 정보로 사용되면 동작 방식이 달라지게 된다.

@Test
void configuration() {
  AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext();
  ac.register(MyConfig.class);
  ac.refersh();
  
  Bean1 bean1 = ac.getBean(Bean1.class);
  Bean2 bean2 = ac.getBean(Bean2.class);
  
  assertThat(bean1.common).isSamdAs(bean2.common) // 성공
}

• proxyBeanMethods = true인 경우 (기본값)
  • Configuration이 붙은 설정 클래스 빈이 직접 등록되는 것이 아닌 프록시로 등록된다.
  • 스프링 내부적으로 프록시는 아래와 같이 동작한다.

@Configuration
static class MyConfigProxy extends MyConfig {
  private Common common;
  
  @Override
  Common common() {
    if (this.common == null) this.common = super.common();
    
    return this.common;
  }
  
  // ...
}

• 스프링 5.2부터 proxyBeanMethods를 false로 변경하는 것이 가능해져 Configuration 빈이 프록시로 대체되지 않는다.
  • 사실 다른 빈 메서드를 호출하여 의존 관계를 설정할 일이 없다면 굳이 프록시를 만들지 않아도 된다.
  • 스프링 내부적으로도 사용되고 있다.

// @EnableScheduling가 import로 가져오는 설정 클래스
@Configuration(proxyBeanMethods = false)
@Rold(BeanDefinition.ROLE_INFRASTRUCTURE)
public class SchedulingConfiguration {
  // ...
}