[Spring Boot Reference V3.0.6] Spring Boot 핵심 기능

핵심 기능

이 섹션에서는 Spring Boot에 대해 자세히 알아봅니다. 여기에서 사용하고 맞춤화할 수 있는 주요 기능에 대해 알아볼 수 있습니다. 아직 그렇게 하지 않았다면 " 시작하기 " 및 " Spring Boot로 개발하기 " 섹션을 읽어 기본 사항에 대한 기초를 잘 다질 수 있습니다.

1. 스프링어플리케이션

이 SpringApplication클래스는 메서드에서 시작되는 Spring 애플리케이션을 부트스트랩하는 편리한 방법을 제공합니다 main(). SpringApplication.run많은 상황에서 다음 예제와 같이 정적 메서드에 위임할 수 있습니다 .

@SpringBootApplication
public class MyApplication {

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

}

 

애플리케이션이 시작되면 다음 출력과 유사한 내용이 표시되어야 합니다.

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.0.6)

2023-04-20T10:09:01.134Z  INFO 20343 --- [           main] o.s.b.d.f.s.MyApplication                : Starting MyApplication using Java 17.0.6 with PID 20343 (/opt/apps/myapp.jar started by myuser in /opt/apps/)
2023-04-20T10:09:01.144Z  INFO 20343 --- [           main] o.s.b.d.f.s.MyApplication                : No active profile set, falling back to 1 default profile: "default"
2023-04-20T10:09:03.394Z  INFO 20343 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-04-20T10:09:03.664Z  INFO 20343 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-04-20T10:09:03.664Z  INFO 20343 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.8]
2023-04-20T10:09:03.840Z  INFO 20343 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2023-04-20T10:09:03.843Z  INFO 20343 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 2345 ms
2023-04-20T10:09:04.616Z  INFO 20343 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2023-04-20T10:09:04.642Z  INFO 20343 --- [           main] o.s.b.d.f.s.MyApplication                : Started MyApplication in 5.022 seconds (process running for 6.616)
2023-04-20T10:09:04.834Z  INFO 20343 --- [ionShutdownHook] o.apache.catalina.core.StandardService   : Stopping service [Tomcat]

기본적으로 INFO애플리케이션을 시작한 사용자와 같은 일부 관련 시작 세부 정보를 포함하여 로깅 메시지가 표시됩니다. 이외의 로그 수준이 필요한 경우 로그 수준INFO 에 설명된 대로 설정할 수 있습니다 . 애플리케이션 버전은 기본 애플리케이션 클래스 패키지의 구현 버전을 사용하여 결정됩니다. 로 설정하여 시작 정보 로깅을 끌 수 있습니다 . 이렇게 하면 애플리케이션의 활성 프로필 로깅도 해제됩니다.spring.main.log-startup-infofalse

시작하는 동안 추가 로깅을 추가하려면 logStartupInfo(boolean)의 하위 클래스에서 재정의할 수 있습니다 SpringApplication.

1.1. 시작 실패

응용 프로그램이 시작되지 않으면 등록된 FailureAnalyzers전용 오류 메시지와 문제 해결을 위한 구체적인 조치를 제공할 기회를 얻습니다. 예를 들어 포트에서 웹 애플리케이션을 시작 8080하고 해당 포트가 이미 사용 중인 경우 다음 메시지와 유사한 내용이 표시됩니다.

***************************
APPLICATION FAILED TO START
***************************

Description:

Embedded servlet container failed to start. Port 8080 was already in use.

Action:

Identify and stop the process that is listening on port 8080 or configure this application to listen on another port.

Spring Boot는 다양한 FailureAnalyzer구현을 제공하며 자신만의 .

오류 분석기가 예외를 처리할 수 없는 경우에도 전체 조건 보고서를 표시하여 무엇이 잘못되었는지 더 잘 이해할 수 있습니다. 이렇게 하려면 속성을 활성화하거나debug 에 대한 로깅을 활성화DEBUGorg.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener 해야 합니다 .

예를 들어 를 사용하여 애플리케이션을 실행하는 경우 다음과 같이 속성을 java -jar활성화할 수 있습니다 .debug

$ java -jar myproject-0.0.1-SNAPSHOT.jar --debug

 

1.2. 지연 초기화

SpringApplication응용 프로그램을 느리게 초기화할 수 있습니다. 지연 초기화가 활성화되면 응용 프로그램 시작 중에가 아니라 필요할 때 Bean이 생성됩니다. 결과적으로 지연 초기화를 활성화하면 애플리케이션을 시작하는 데 걸리는 시간을 줄일 수 있습니다. 웹 애플리케이션에서 지연 초기화를 활성화하면 HTTP 요청이 수신될 때까지 많은 웹 관련 Bean이 초기화되지 않습니다.

지연 초기화의 단점은 응용 프로그램의 문제 발견을 지연시킬 수 있다는 것입니다. 잘못 구성된 빈이 느리게 초기화되면 시작 중에 더 이상 오류가 발생하지 않으며 빈이 초기화될 때만 문제가 분명해집니다. JVM에 시작 중에 초기화되는 빈뿐만 아니라 모든 애플리케이션 빈을 수용할 수 있는 충분한 메모리가 있는지 확인해야 합니다. 이러한 이유로 지연 초기화는 기본적으로 활성화되어 있지 않으며 지연 초기화를 활성화하기 전에 JVM의 힙 크기를 미세 조정하는 것이 좋습니다.

lazyInitialization지연 초기화는 on 메서드 SpringApplicationBuilder또는 setLazyInitializationon 메서드를 사용하여 프로그래밍 방식으로 활성화할 수 있습니다 SpringApplication. 또는 spring.main.lazy-initialization다음 예와 같이 속성을 사용하여 활성화할 수 있습니다.

spring.main.lazy-initialization=true

 

나머지 응용 프로그램에 대해 지연 초기화를 사용하는 동안 특정 빈에 대해 지연 초기화를 비활성화하려면 주석을 사용하여 명시적으로 지연 속성을 false로 설정할 수 있습니다 @Lazy(false).

1.3. 배너 사용자 지정

시작할 때 인쇄되는 배너는 banner.txt클래스 경로에 파일을 추가하거나 spring.banner.location속성을 해당 파일의 위치로 설정하여 변경할 수 있습니다. 파일에 UTF-8 이외의 인코딩이 있는 경우 spring.banner.charset.

파일 내에서 사용 가능한 모든 키 와 다음 자리 표시자를 banner.txt사용할 수 있습니다 .Environment

표 1. 배너 변수변하기 쉬운설명

${application.version}	에 선언된 애플리케이션의 버전 번호입니다 MANIFEST.MF. 예를 들어 는 로 Implementation-Version: 1.0인쇄됩니다 1.0.
${application.formatted-version}	에서 선언되고 표시 형식이 지정된 애플리케이션의 버전 번호입니다 MANIFEST.MF(대괄호로 둘러싸이고 로 시작 v). 예를 들어 (v1.0).
${spring-boot.version}	사용 중인 Spring Boot 버전입니다. 예를 들어 3.0.6.
${spring-boot.formatted-version}	사용 중인 Spring Boot 버전으로, 표시용으로 형식이 지정되어 있습니다(대괄호로 둘러싸이고 로 시작 v). 예를 들어 (v3.0.6).
${Ansi.NAME}(또는 ${AnsiColor.NAME}, ${AnsiBackground.NAME}, ${AnsiStyle.NAME})	NAMEANSI 이스케이프 코드의 이름은 어디에 있습니까? 자세한 내용은 참조하십시오 AnsiPropertySource.
${application.title}	에 선언된 응용 프로그램의 제목입니다 MANIFEST.MF. 예를 들어 는 로 Implementation-Title: MyApp인쇄됩니다 MyApp.

SpringApplication.setBanner(…​)프로그래밍 방식으로 배너를 생성하려는 경우 이 방법을 사용할 수 있습니다. 인터페이스를 사용 org.springframework.boot.Banner하고 자신의 printBanner()방법을 구현하십시오.

spring.main.banner-mode속성을 사용하여 배너를 인쇄해야 하는지 System.out( console), 구성된 로거로 보내야 하는지( log) 또는 전혀 생성하지 않아야 하는지( off)를 결정할 수도 있습니다 .

인쇄된 배너는 다음 이름으로 싱글톤 빈으로 등록됩니다 springBootBanner.

${application.version}및 속성 ${application.formatted-version}은 Spring Boot 시작 관리자를 사용하는 경우에만 사용할 수 있습니다. 압축을 푼 jar를 실행하고 java -cp <classpath> <mainclass>. This is why we recommend that you always launch unpacked jars using java org.springframework.boot.loader.JarLauncher. This will initialize the application.* banner variables before building the classpath and launching your app.

1.4. 스프링 애플리케이션 커스터마이징

기본값 SpringApplication이 마음에 들지 않으면 대신 로컬 인스턴스를 만들고 사용자 정의할 수 있습니다. 예를 들어 배너를 끄려면 다음과 같이 작성할 수 있습니다.

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(MyApplication.class);
        application.setBannerMode(Banner.Mode.OFF);
        application.run(args);
    }

}

 

전달된 생성자 인수는 SpringApplicationSpring Bean의 구성 소스입니다. 대부분의 경우 이들은 클래스에 대한 참조 @Configuration이지만 직접 참조 클래스일 수도 있습니다 @Component.

 

SpringApplication파일을 사용하여 구성하는 것도 가능합니다 application.properties. 자세한 내용은 외부화된 구성을 참조하십시오 .

구성 옵션의 전체 목록은 SpringApplicationJavadoc 를 참조하십시오 .

1.5. 유창한 빌더 API

계층 구조(부모/자식 관계가 있는 여러 컨텍스트) 를 구축해야 하거나 ApplicationContext"유창한" 빌더 API 사용을 선호하는 경우 SpringApplicationBuilder.

를 사용하면 다음 예제와 같이 계층 구조를 만들 수 있는 SpringApplicationBuilder여러 메서드 호출과 포함 parent및 메서드를 함께 연결할 수 있습니다.child

new SpringApplicationBuilder()
        .sources(Parent.class)
        .child(Application.class)
        .bannerMode(Banner.Mode.OFF)
        .run(args);

 

계층 구조 를 만들 때 몇 가지 제한 사항이 있습니다 ApplicationContext. 예를 들어 웹 구성 요소는 하위 컨텍스트 내에 포함되어야 하며Environment 상위 및 하위 컨텍스트 모두에 동일하게 사용됩니다. 자세한 내용은 SpringApplicationBuilderJavadoc을 참조하십시오 .

1.6. 애플리케이션 가용성

플랫폼에 배포될 때 애플리케이션은 Kubernetes 프로브 와 같은 인프라를 사용하여 플랫폼에 가용성에 대한 정보를 제공할 수 있습니다 . Spring Boot에는 일반적으로 사용되는 "활성" 및 "준비" 가용성 상태에 대한 기본 지원이 포함되어 있습니다. Spring Boot의 "액추에이터" 지원을 사용하는 경우 이러한 상태는 상태 엔드포인트 그룹으로 노출됩니다.

또한 ApplicationAvailability자신의 Bean에 인터페이스를 주입하여 가용성 상태를 얻을 수도 있습니다.

1.6.1. 활성 상태

응용 프로그램의 "활성" 상태는 내부 상태가 응용 프로그램이 올바르게 작동하도록 허용하는지 또는 현재 오류가 발생한 경우 자체적으로 복구할 수 있는지 여부를 알려줍니다. 중단된 "활성" 상태는 응용 프로그램이 복구할 수 없는 상태에 있으며 인프라가 응용 프로그램을 다시 시작해야 함을 의미합니다.

일반적으로 "활성" 상태는 상태 확인과 같은 외부 확인을 기반으로 해서는 안 됩니다 . 만약 그렇다면 외부 시스템(데이터베이스, 웹 API, 외부 캐시)의 실패로 인해 플랫폼 전체에서 대량 재시작 및 계단식 오류가 발생합니다.

Spring Boot 애플리케이션의 내부 상태는 대부분 Spring으로 표시됩니다 ApplicationContext. 애플리케이션 컨텍스트가 성공적으로 시작된 경우 Spring Boot는 애플리케이션이 유효한 상태에 있다고 가정합니다. 애플리케이션은 컨텍스트가 새로 고쳐지는 즉시 활성 상태로 간주됩니다. Spring Boot 애플리케이션 수명 주기 및 관련 애플리케이션 이벤트를 참조하세요 .

1.6.2. 준비 상태

애플리케이션의 "준비" 상태는 애플리케이션이 트래픽을 처리할 준비가 되었는지 여부를 알려줍니다. 실패한 "준비" 상태는 플랫폼에 현재 트래픽을 애플리케이션으로 라우팅하지 않아야 함을 알려줍니다. 이것은 일반적으로 시작하는 동안, 구성 요소가 처리되는 동안 또는 응용 프로그램이 추가 트래픽에 대해 너무 바쁘다고 결정하는 경우 언제든지 발생 CommandLineRunner합니다 ApplicationRunner.

애플리케이션 및 명령줄 실행기가 호출되는 즉시 애플리케이션이 준비된 것으로 간주됩니다. Spring Boot 애플리케이션 수명 주기 및 관련 애플리케이션 이벤트를 참조하세요 .

시작하는 동안 실행될 것으로 예상되는 CommandLineRunner작업 ApplicationRunner은 @PostConstruct.

1.6.3. 애플리케이션 가용성 상태 관리

ApplicationAvailability응용 프로그램 구성 요소는 인터페이스를 삽입하고 인터페이스에서 메서드를 호출하여 언제든지 현재 가용성 상태를 검색할 수 있습니다 . 더 자주 애플리케이션은 상태 업데이트를 수신하거나 애플리케이션의 상태를 업데이트하려고 합니다.

예를 들어 Kubernetes "exec Probe"가 이 파일을 볼 수 있도록 애플리케이션의 "Readiness" 상태를 파일로 내보낼 수 있습니다.

@Component
public class MyReadinessStateExporter {

    @EventListener
    public void onStateChange(AvailabilityChangeEvent<ReadinessState> event) {
        switch (event.getState()) {
            case ACCEPTING_TRAFFIC:
                // create file /tmp/healthy
                break;
            case REFUSING_TRAFFIC:
                // remove file /tmp/healthy
                break;
        }
    }

}

애플리케이션이 중단되어 복구할 수 없는 경우 애플리케이션의 상태를 업데이트할 수도 있습니다.

 

@Component
public class MyLocalCacheVerifier {

    private final ApplicationEventPublisher eventPublisher;

    public MyLocalCacheVerifier(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void checkLocalCache() {
        try {
            // ...
        }
        catch (CacheCompletelyBrokenException ex) {
            AvailabilityChangeEvent.publish(this.eventPublisher, ex, LivenessState.BROKEN);
        }
    }

}

 

Spring Boot는 Actuator Health Endpoints와 함께 "활성" 및 "준비"를 위한 Kubernetes HTTP 프로브를 제공합니다 . 전용 섹션에서 Kubernetes에 Spring Boot 애플리케이션을 배포하는 방법 에 대한 자세한 지침을 얻을 수 있습니다 .

1.7. 애플리케이션 이벤트 및 리스너

와 같은 일반적인 Spring Framework 이벤트 외에도 일부 추가 애플리케이션 이벤트를 ContextRefreshedEvent보냅니다 SpringApplication.

일부 이벤트는 가 생성되기 전에 실제로 트리거되므로 ApplicationContext리스너를 로 등록할 수 없습니다 @Bean. SpringApplication.addListeners(…​)메소드 또는 메소드 로 등록할 수 있습니다 SpringApplicationBuilder.listeners(…​). 해당 리스너가 자동으로 등록되도록 하려면 애플리케이션 생성 방식에 관계없이 META-INF/spring.factories프로젝트에 파일을 추가하고 org.springframework.context.ApplicationListener다음 예제와 같이 키를 사용하여 리스너를 참조할 수 있습니다. org.springframework.context.ApplicationListener=com.example.project.MyListener

애플리케이션 이벤트는 애플리케이션이 실행될 때 다음 순서로 전송됩니다.

1. An은 ApplicationStartingEvent실행 시작 시 전송되지만 리스너 및 이니셜라이저 등록을 제외한 모든 처리 전에 전송됩니다.
2. 컨텍스트에서 사용할 을 알고 있지만 컨텍스트가 생성되기 전에 An이 ApplicationEnvironmentPreparedEvent전송됩니다 .Environment
3. 가 준비되고 ApplicationContextInitializers가 호출되었지만 bean 정의가 로드되기 전에 An이 ApplicationContextInitializedEvent전송됩니다 .ApplicationContext
4. ApplicationPreparedEvent새로 고침이 시작되기 직전에 빈 정의가 로드된 후에 An이 전송됩니다.
5. An은 ApplicationStartedEvent컨텍스트가 새로 고쳐진 후 애플리케이션 및 명령줄 실행기가 호출되기 전에 전송됩니다.
6. 응용 프로그램이 라이브로 간주됨을 나타내기 위해 AvailabilityChangeEventwith 바로 뒤에 An이 전송됩니다.LivenessState.CORRECT
7. 응용 프로그램 및 명령줄 실행기가 호출된 후에 An이 ApplicationReadyEvent전송됩니다 .
8. 응용 프로그램이 요청을 처리할 준비가 되었음을 나타내기 위해 with AvailabilityChangeEvent바로 뒤에 가 전송됩니다 .ReadinessState.ACCEPTING_TRAFFIC
9. ApplicationFailedEvent시작 시 예외가 있으면 An이 전송됩니다.

위의 목록에는 SpringApplicationEvent에 연결된 s 만 포함됩니다 SpringApplication. 이 외에도 다음과 같은 이벤트가 전후에 게시 ApplicationPreparedEvent됩니다 ApplicationStartedEvent.

• A는 가 준비된 WebServerInitializedEvent후에 전송됩니다 . 각각 서블릿 및 반응형 변형입니다 .WebServerServletWebServerInitializedEventReactiveWebServerInitializedEvent
• an이 새로 고쳐 지면 A가 ContextRefreshedEvent전송됩니다 .ApplicationContext

응용 프로그램 이벤트를 사용할 필요가 없는 경우가 많지만 이벤트가 존재한다는 사실을 알고 있으면 편리합니다. 내부적으로 Spring Boot는 이벤트를 사용하여 다양한 작업을 처리합니다.

이벤트 리스너는 기본적으로 동일한 스레드에서 실행되므로 잠재적으로 시간이 오래 걸리는 작업을 실행하면 안 됩니다. 대신 응용 프로그램 및 명령줄 실행기를 사용하는 것이 좋습니다 .

애플리케이션 이벤트는 Spring Framework의 이벤트 게시 메커니즘을 사용하여 전송됩니다. 이 메커니즘의 일부는 하위 컨텍스트의 리스너에 게시된 이벤트가 모든 상위 컨텍스트의 리스너에도 게시되도록 합니다. 결과적으로 애플리케이션이 인스턴스 계층을 사용하는 경우 SpringApplication리스너는 동일한 유형의 애플리케이션 이벤트의 여러 인스턴스를 수신할 수 있습니다.

리스너가 해당 컨텍스트에 대한 이벤트와 하위 컨텍스트에 대한 이벤트를 구분할 수 있도록 하려면 애플리케이션 컨텍스트가 삽입되도록 요청한 다음 삽입된 컨텍스트를 이벤트 컨텍스트와 비교해야 합니다. 컨텍스트는 구현하거나 ApplicationContextAware리스너가 빈인 경우 를 사용하여 주입할 수 있습니다 @Autowired.

1.8. 웹 환경

A는 귀하를 대신하여 SpringApplication올바른 유형의 작성을 시도합니다 . ApplicationContexta를 결정하는 데 사용되는 알고리즘은 WebApplicationType다음과 같습니다.

• Spring MVC가 있으면 an이 AnnotationConfigServletWebServerApplicationContext사용됩니다.
• Spring MVC가 없고 Spring WebFlux가 있으면 an이 AnnotationConfigReactiveWebServerApplicationContext사용됩니다.
• 그렇지 않으면 AnnotationConfigApplicationContext사용됩니다.

 

즉, WebClient동일한 애플리케이션에서 Spring MVC와 Spring WebFlux의 새 기능을 사용하는 경우 Spring MVC가 기본적으로 사용됩니다. 를 호출하여 쉽게 재정의할 수 있습니다 setWebApplicationType(WebApplicationType).

ApplicationContext를 호출하여 사용되는 형식을 완전히 제어할 수도 있습니다 setApplicationContextFactory(…​).

JUnit 테스트 내에서 setWebApplicationType(WebApplicationType.NONE)사용할 때 호출하는 것이 종종 바람직합니다 .SpringApplication

1.9. 애플리케이션 인수 액세스

에 전달된 애플리케이션 인수에 액세스해야 하는 경우 빈 SpringApplication.run(…​)을 주입할 수 있습니다 org.springframework.boot.ApplicationArguments. 인터페이스 는 다음 예제와 같이 ApplicationArguments원시 String[]인수와 구문 분석 option및 인수 모두에 대한 액세스를 제공합니다.non-option

@Component
public class MyBean {

    public MyBean(ApplicationArguments args) {
        boolean debug = args.containsOption("debug");
        List<String> files = args.getNonOptionArgs();
        if (debug) {
            System.out.println(files);
        }
        // if run with "--debug logfile.txt" prints ["logfile.txt"]
    }

}

 

Spring Boot는 또한 CommandLinePropertySourceSpring에 a를 등록합니다 Environment. 이렇게 하면 주석을 사용하여 단일 애플리케이션 인수를 삽입할 수도 있습니다 @Value.

1.10. ApplicationRunner 또는 CommandLineRunner 사용

가 시작된 후 일부 특정 코드를 실행해야 하는 경우 또는 인터페이스를 SpringApplication구현할 수 있습니다 . 두 인터페이스 모두 동일한 방식으로 작동하며 완료 직전에 호출되는 단일 메서드를 제공합니다 .ApplicationRunnerCommandLineRunnerrunSpringApplication.run(…​)

이 계약은 애플리케이션 시작 후 트래픽 수락을 시작하기 전에 실행해야 하는 작업에 매우 적합합니다.

인터페이스 CommandLineRunner는 문자열 배열로 응용 프로그램 인수에 대한 액세스를 제공하지만 앞서 설명한 인터페이스를 ApplicationRunner사용합니다 . ApplicationArguments다음 예제는 메서드 CommandLineRunner가 있는 a를 보여줍니다 run.

@Component
public class MyCommandLineRunner implements CommandLineRunner {

    @Override
    public void run(String... args) {
        // Do something...
    }

}

 

CommandLineRunner특정 순서로 호출해야 하는 Bean 이 여러 개 정의된 경우 인터페이스를 추가로 구현하거나 주석을 사용할 ApplicationRunner수 있습니다 .org.springframework.core.Orderedorg.springframework.core.annotation.Order

1.11. 애플리케이션 종료

각각은 종료 시 정상적으로 닫히도록 SpringApplicationJVM에 종료 후크를 등록합니다 . ApplicationContext모든 표준 Spring 수명 주기 콜백(예: DisposableBean인터페이스 또는 @PreDestroy주석)을 사용할 수 있습니다.

또한 bean은 호출될 org.springframework.boot.ExitCodeGenerator때 특정 종료 코드를 반환하려는 경우 인터페이스를 구현할 수 있습니다 SpringApplication.exit(). 그런 다음 이 종료 코드를 에 전달하여 System.exit()다음 예와 같이 상태 코드로 반환할 수 있습니다.

@SpringBootApplication
public class MyApplication {

    @Bean
    public ExitCodeGenerator exitCodeGenerator() {
        return () -> 42;
    }

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

}

 

또한 ExitCodeGenerator인터페이스는 예외에 의해 구현될 수 있습니다. 이러한 예외가 발생하면 Spring Boot는 구현된 getExitCode()메서드에서 제공하는 종료 코드를 반환합니다.

둘 이상이 있는 경우 ExitCodeGenerator생성된 0이 아닌 첫 번째 종료 코드가 사용됩니다. 제너레이터가 호출되는 순서를 제어하려면 org.springframework.core.Ordered인터페이스를 추가로 구현하거나 주석을 사용하십시오 org.springframework.core.annotation.Order.

1.12. 관리 기능

속성 을 지정하여 애플리케이션에 대한 관리자 관련 기능을 활성화할 수 있습니다 spring.application.admin.enabled. 이렇게 하면 SpringApplicationAdminMXBean플랫폼에 가 노출됩니다 MBeanServer. 이 기능을 사용하여 Spring Boot 애플리케이션을 원격으로 관리할 수 있습니다. 이 기능은 모든 서비스 래퍼 구현에도 유용할 수 있습니다.

If you want to know on which HTTP port the application is running, get the property with a key of local.server.port.

1.13. 애플리케이션 시작 추적

애플리케이션 시작 중에 및 는 애플리케이션 수명 주기, 빈 수명 주기 또는 애플리케이션 이벤트 처리와 관련된 많은 작업을 수행합니다 SpringApplication. ApplicationContext를 사용하면 ApplicationStartupSpring Framework를 사용하여 객체 로 애플리케이션 시작 시퀀스를 추적할 수 있습니다StartupStep . 이 데이터는 프로파일링 목적으로 수집하거나 애플리케이션 시작 프로세스를 더 잘 이해하기 위해 수집할 수 있습니다.

ApplicationStartup인스턴스 를 설정할 때 구현을 선택할 수 있습니다 SpringApplication. 예를 들어 를 사용하려면 다음과 BufferingApplicationStartup같이 작성할 수 있습니다.

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(MyApplication.class);
        application.setApplicationStartup(new BufferingApplicationStartup(2048));
        application.run(args);
    }

}

 

사용 가능한 첫 번째 구현은 FlightRecorderApplicationStartupSpring Framework에서 제공됩니다. Java Flight Recorder 세션에 Spring 관련 시작 이벤트를 추가하고 애플리케이션을 프로파일링하고 Spring 컨텍스트 수명 주기를 JVM 이벤트(예: 할당, GC, 클래스 로딩 등)와 연관시키기 위한 것입니다. 일단 구성되면 Flight Recorder를 활성화한 상태에서 애플리케이션을 실행하여 데이터를 기록할 수 있습니다.

$ java -XX:StartFlightRecording:filename=recording.jfr,duration=10s -jar demo.jar

 

Spring Boot는 BufferingApplicationStartup변형과 함께 제공됩니다. 이 구현은 시작 단계를 버퍼링하고 이를 외부 메트릭 시스템으로 배출하기 위한 것입니다. BufferingApplicationStartup응용 프로그램은 모든 구성 요소에서 빈 유형을 요청할 수 있습니다 .

startup이 정보를 JSON 문서로 제공하는 끝점을 노출하도록 Spring Boot를 구성할 수도 있습니다 .

2. 구체화된 구성

Spring Boot를 사용하면 다른 환경에서 동일한 애플리케이션 코드로 작업할 수 있도록 구성을 외부화할 수 있습니다. Java 속성 파일, YAML 파일, 환경 변수 및 명령줄 인수를 비롯한 다양한 외부 구성 소스를 사용할 수 있습니다.

속성 값은 주석을 사용하여 빈에 직접 주입하거나 @ValueSpring의 추상화를 통해 Environment액세스하거나 를 통해 구조화된 개체에 바인딩@ConfigurationProperties 할 수 있습니다 .

PropertySourceSpring Boot는 합리적인 값 재정의를 허용하도록 설계된 매우 특별한 순서를 사용합니다 . 이후 속성 소스는 이전 속성 소스에서 정의된 값을 재정의할 수 있습니다. 소스는 다음 순서로 고려됩니다.

1. 기본 속성( 설정으로 지정됨 SpringApplication.setDefaultProperties).
2. @PropertySource수업 에 대한 주석 @Configuration. Environment이러한 속성 소스는 애플리케이션 컨텍스트가 새로 고쳐질 때까지 에 추가되지 않습니다 . 새로 고침이 시작되기 전에 읽히는 logging.*및 등의 특정 속성을 구성하기에는 너무 늦었습니다 .spring.main.*
3. 구성 데이터(예: application.properties파일).
4. RandomValuePropertySource에만 속성이 random.*있는 A.
5. OS 환경 변수.
6. Java 시스템 속성( System.getProperties()).
7. . java:comp/env_
8. ServletContext초기화 매개변수.
9. ServletConfig초기화 매개변수.
10. SPRING_APPLICATION_JSON(환경 변수 또는 시스템 속성에 포함된 인라인 JSON) 의 속성 .
11. 명령줄 인수.
12. properties테스트의 속성. 응용 프로그램의 특정 조각을 테스트하기 위한@SpringBootTest 및 테스트 주석 에서 사용할 수 있습니다 .
13. @TestPropertySource테스트에 대한 주석.
14. devtools가 활성 상태일 때 디렉터리 의 Devtools 전역 설정 속성입니다$HOME/.config/spring-boot .

구성 데이터 파일은 다음 순서로 고려됩니다.

1. jar( 및 YAML 변형) 내부에 패키징된 애플리케이션 속성application.properties .
2. jar( application-{profile}.properties및 YAML 변형) 내에 패키징된 프로필별 애플리케이션 속성 .
3. 패키징된 jar( application.properties및 YAML 변형) 외부의 애플리케이션 속성 .
4. 패키지된 jar( application-{profile}.properties및 YAML 변형) 외부의 프로필별 애플리케이션 속성입니다 .

전체 애플리케이션에 대해 하나의 형식을 고수하는 것이 좋습니다. 동일한 위치에 .properties및 형식이 모두 포함된 구성 파일이 있는 경우 가 우선합니다. .yml.properties

구체적인 예를 제공하기 위해 다음 예와 같이 속성을 @Component사용하는 를 개발한다고 가정합니다.name

@Component
public class MyBean {

    @Value("${name}")
    private String name;

    // ...

}

 

application.properties애플리케이션 클래스 경로(예: jar 내부)에서 name. 새 환경에서 실행하는 경우 application.propertiesjar 외부에서 name. 일회성 테스트의 경우 특정 명령줄 스위치(예: java -jar app.jar --name="Spring")를 사용하여 시작할 수 있습니다.

env및 끝점 configprops은 속성에 특정 값이 있는 이유를 확인하는 데 유용할 수 있습니다. 이 두 끝점을 사용하여 예기치 않은 속성 값을 진단할 수 있습니다. 자세한 내용은 " 프로덕션 준비 기능 " 섹션을 참조하십시오.

2.1. 명령줄 속성 액세스

기본적으로 SpringApplication모든 명령줄 옵션 인수(즉, --와 같이 로 시작하는 인수 --server.port=9000)를 a로 변환 property하고 Spring에 추가합니다 Environment. 앞에서 언급했듯이 명령줄 속성은 항상 파일 기반 속성 소스보다 우선합니다.

명령줄 속성을 에 추가하지 않으려면 Environment를 사용하여 비활성화할 수 있습니다 SpringApplication.setAddCommandLineProperties(false).

2.2. JSON 애플리케이션 속성

환경 변수 및 시스템 속성에는 종종 일부 속성 이름을 사용할 수 없음을 의미하는 제한이 있습니다. 이를 돕기 위해 Spring Boot를 사용하면 속성 블록을 단일 JSON 구조로 인코딩할 수 있습니다.

애플리케이션이 시작되면 any spring.application.json또는 SPRING_APPLICATION_JSON속성이 구문 분석되어 Environment.

예를 들어 SPRING_APPLICATION_JSON환경 변수로 UN*X 셸의 명령줄에 속성을 제공할 수 있습니다.

$ SPRING_APPLICATION_JSON='{"my":{"name":"test"}}' java -jar myapp.jar

 

my.name=test앞의 예에서 Spring 으로 끝납니다 Environment.

동일한 JSON을 시스템 속성으로 제공할 수도 있습니다.

$ java -Dspring.application.json='{"my":{"name":"test"}}' -jar myapp.jar

 

또는 명령줄 인수를 사용하여 JSON을 제공할 수 있습니다.

$ java -jar myapp.jar --spring.application.json='{"my":{"name":"test"}}'

 

기존 애플리케이션 서버에 배포하는 경우 이라는 JNDI 변수를 사용할 수도 있습니다 java:comp/env/spring.application.json.

nullJSON의 값이 결과 속성 소스에 추가되더라도 속성 은 누락된 값으로 PropertySourcesPropertyResolver처리됩니다 null. 이는 JSON이 하위 속성 소스의 속성을 값으로 재정의할 수 없음을 의미합니다 null.

2.3. 외부 애플리케이션 속성

Spring Boot는 애플리케이션이 시작될 때 다음 위치에서 자동으로 파일을 찾아 application.properties로드 합니다 .application.yaml

1. 클래스 경로에서
   1. 클래스패스 루트
   2. 클래스패스 /config패키지
2. 현재 디렉터리에서
   1. 현재 디렉터리
   2. config/현재 디렉토리의 하위 디렉토리
   3. config/하위 디렉토리 의 직계 하위 디렉토리

목록은 우선 순위에 따라 정렬됩니다(하위 항목의 값이 이전 항목보다 우선함). PropertySources로드된 파일의 문서가 Spring에 추가됩니다 Environment.

application구성 파일 이름이 마음에 들지 않으면 spring.config.name환경 속성을 지정하여 다른 파일 이름으로 전환할 수 있습니다. myproject.properties예를 들어 및 파일을 찾으려면 myproject.yaml다음과 같이 애플리케이션을 실행할 수 있습니다.

$ java -jar myproject.jar --spring.config.name=myproject

 

 

환경 속성을 사용하여 명시적 위치를 참조할 수도 있습니다 spring.config.location. 이 속성은 확인할 하나 이상의 위치가 쉼표로 구분된 목록을 허용합니다.

다음 예에서는 두 개의 개별 파일을 지정하는 방법을 보여줍니다.

$ java -jar myproject.jar --spring.config.location=\
    optional:classpath:/default.properties,\
    optional:classpath:/override.properties

 

위치가 선택 사항optional: 이고 위치 가 없어도 괜찮다면 접두사를 사용하십시오 .

spring.config.name, spring.config.location및 는 spring.config.additional-location로드해야 하는 파일을 결정하는 데 아주 일찍 사용됩니다. 환경 속성(일반적으로 OS 환경 변수, 시스템 속성 또는 명령줄 인수)으로 정의해야 합니다.

spring.config.location디렉토리(파일이 아닌)를 포함하는 경우 /. spring.config.name런타임 시 로드 되기 전에 생성된 이름이 추가됩니다 . 에 지정된 파일을 spring.config.location직접 가져옵니다.

프로필별 파일을 확인하기 위해 디렉터리 및 파일 위치 값도 확장됩니다 . spring.config.location예를 들어 of 가 있으면 적절한 파일 classpath:myconfig.properties도 로드됩니다 .classpath:myconfig-<profile>.properties

대부분의 경우 spring.config.location추가하는 각 항목은 단일 파일 또는 디렉토리를 참조합니다. 위치는 정의된 순서대로 처리되며 이후 위치는 이전 위치의 값을 재정의할 수 있습니다.

복잡한 위치 설정이 있고 프로필별 구성 파일을 사용하는 경우 Spring Boot가 그룹화 방법을 알 수 있도록 추가 힌트를 제공해야 할 수 있습니다. 위치 그룹은 모두 동일한 수준으로 간주되는 위치 모음입니다. 예를 들어 모든 클래스 경로 위치를 그룹화한 다음 모든 외부 위치를 그룹화할 수 있습니다. 위치 그룹 내의 항목은 로 구분해야 합니다 ;. 자세한 내용은 " 프로필 특정 파일 " 섹션 의 예를 참조하십시오 .

를 사용하여 구성된 위치는 spring.config.location기본 위치를 바꿉니다. 예를 들어 가 spring.config.location값으로 구성된 경우 optional:classpath:/custom-config/,optional:file:./custom-config/고려되는 전체 위치 세트는 다음과 같습니다.

1. optional:classpath:custom-config/
2. optional:file:./custom-config/

위치를 교체하는 대신 추가 위치를 선호하는 경우 를 사용할 수 있습니다 spring.config.additional-location. 추가 위치에서 로드된 속성은 기본 위치의 속성을 재정의할 수 있습니다. 예를 들어 가 spring.config.additional-location값으로 구성된 경우 optional:classpath:/custom-config/,optional:file:./custom-config/고려되는 전체 위치 세트는 다음과 같습니다.

1. optional:classpath:/;optional:classpath:/config/
2. optional:file:./;optional:file:./config/;optional:file:./config/*/
3. optional:classpath:custom-config/
4. optional:file:./custom-config/

이 검색 순서를 사용하면 하나의 구성 파일에서 기본값을 지정한 다음 해당 값을 다른 파일에서 선택적으로 재정의할 수 있습니다. 기본 위치 중 하나에서 application.properties(또는 로 선택한 다른 기본 이름 ) 애플리케이션에 대한 기본값을 제공할 수 있습니다 . spring.config.name이러한 기본값은 사용자 지정 위치 중 하나에 있는 다른 파일을 사용하여 런타임에 재정의할 수 있습니다.

시스템 속성이 아닌 환경 변수를 사용하는 경우 대부분의 운영 체제는 마침표로 구분된 키 이름을 허용하지 않지만 대신 밑줄을 사용할 수 있습니다(예: SPRING_CONFIG_NAME대신 spring.config.name). 자세한 내용은 환경 변수에서 바인딩을 참조하십시오 .

애플리케이션이 서블릿 컨테이너 또는 애플리케이션 서버에서 실행되는 경우 JNDI 속성(에서 java:comp/env) 또는 서블릿 컨텍스트 초기화 매개변수를 환경 변수 또는 시스템 속성 대신 사용할 수 있습니다.

2.3.1. 선택적 위치

기본적으로 지정된 구성 데이터 위치가 존재하지 않으면 Spring Boot에서 오류가 발생 ConfigDataLocationNotFoundException하고 애플리케이션이 시작되지 않습니다.

위치를 지정하고 싶지만 항상 존재하지 않아도 괜찮다면 접두사를 사용할 수 있습니다 optional:. 선언 뿐만 아니라 spring.config.location및 속성 에도 이 접두사를 사용할 수 있습니다 .spring.config.additional-locationspring.config.import

예를 들어 spring.config.import값이 이면 파일이 optional:file:./myconfig.properties없어도 애플리케이션을 시작할 수 있습니다 myconfig.properties.

모두 무시 ConfigDataLocationNotFoundExceptions하고 항상 응용 프로그램을 계속 시작하려면 spring.config.on-not-found속성을 사용할 수 있습니다. 시스템/환경 변수를 ignore사용 하거나 함께 값을 설정합니다 .SpringApplication.setDefaultProperties(…​)

2.3.2. 와일드카드 위치

구성 파일 위치에 *마지막 경로 세그먼트의 문자가 포함되어 있으면 와일드카드 위치로 간주됩니다. 구성이 로드될 때 와일드카드가 확장되어 바로 하위 디렉토리도 확인됩니다. 와일드카드 위치는 구성 속성의 소스가 여러 개인 경우 Kubernetes와 같은 환경에서 특히 유용합니다.

예를 들어 일부 Redis 구성과 일부 MySQL 구성이 있는 경우 이 두 가지 구성을 별도로 유지하면서 둘 다 파일에 있어야 할 수 있습니다 application.properties. 이로 인해 및 와 application.properties같이 서로 다른 위치에 두 개의 개별 파일이 마운트 될 수 있습니다 . 이러한 경우 와일드카드 위치가 이면 두 파일이 모두 처리됩니다./config/redis/application.properties/config/mysql/application.propertiesconfig/*/

기본적으로 Spring Boot는 config/*/기본 검색 위치에 포함됩니다. /configjar 외부 디렉토리 의 모든 하위 디렉토리가 검색됨을 의미합니다 .

spring.config.location및 속성 과 함께 와일드카드 위치를 직접 사용할 수 있습니다 spring.config.additional-location.

와일드카드 위치는 하나만 포함해야 하며 디렉토리인 검색 위치 또는 파일인 검색 위치로 *끝나야 합니다 . 와일드카드가 있는 위치는 파일 이름의 절대 경로를 기준으로 알파벳순으로 정렬됩니다. */*/<filename>

와일드카드 위치는 외부 디렉터리에서만 작동합니다. 위치 에 와일드카드를 사용할 수 없습니다 classpath:.

2.3.3. Profile Specific Files

속성 파일 과 마찬가지로 applicationSpring Boot는 명명 규칙을 사용하여 프로필별 파일을 로드하려고 시도합니다 application-{profile}. 예를 들어 애플리케이션이 이름이 지정된 프로필을 활성화 prod하고 YAML 파일을 사용하는 경우 application.yml및 둘 다 application-prod.yml고려됩니다.

프로파일 특정 속성은 standard 와 동일한 위치에서 로드되며 application.properties프로파일 특정 파일은 항상 비특정 파일을 재정의합니다. 여러 프로필이 지정된 경우 최종 성공 전략이 적용됩니다. 예를 들어 프로필이 속성 prod,live으로 지정된 경우 의 spring.profiles.active값을 의 값으로 application-prod.properties재정의할 수 있습니다 application-live.properties.

최종 성공 전략은 위치 그룹 수준에서 적용됩니다. spring.config.location의 A 는 classpath:/cfg/,classpath:/ext/과 동일한 재정의 규칙을 갖지 않습니다 classpath:/cfg/;classpath:/ext/. 예를 들어 prod,live위의 예를 계속하면 다음 파일이 있을 수 있습니다.   spring.config.locationof가 있으면 모든 파일보다 먼저 모든 파일을 classpath:/cfg/,classpath:/ext/처리합니다 ./cfg/ext /cfg/application-live.properties /ext/application-prod.properties /ext/application-live.properties 대신에 classpath:/cfg/;classpath:/ext/(구분 기호 사용 ) 다음과 같은 수준에서 ;처리합니다 ./cfg/ext /ext/application-prod.properties /cfg/application-live.properties /ext/application-live.properties

에는 활성 프로필이 설정되지 않은 경우 사용되는 Environment기본 프로필 세트(기본적으로 )가 있습니다 . [default]즉, 프로필이 명시적으로 활성화되지 않은 경우 의 속성이 application-default고려됩니다.

속성 파일은 한 번만 로드됩니다. 프로필 특정 속성 파일을 이미 직접 가져온 경우 두 번째로 가져오지 않습니다.

2.3.4. 추가 데이터 가져오기

응용 프로그램 속성은 속성을 사용하여 다른 위치에서 추가 구성 데이터를 가져올 수 있습니다 spring.config.import. 수입품은 발견되는 대로 처리되며 수입품을 신고한 문서 바로 아래에 삽입된 추가 문서로 처리됩니다.

예를 들어 클래스 경로 파일에 다음이 있을 수 있습니다 application.properties.

spring.application.name=myapp
spring.config.import=optional:file:./dev.properties

 

이렇게 하면 현재 디렉터리에 파일 가져오기가 트리거됩니다 dev.properties(해당 파일이 있는 경우). 가져온 값은 dev.properties가져오기를 트리거한 파일보다 우선합니다. 위의 예에서 는 다른 값으로 dev.properties재정의할 수 있습니다 .spring.application.name

가져오기는 선언 횟수에 관계없이 한 번만 가져옵니다. 속성/yaml 파일 내의 단일 문서 내에서 가져오기가 정의되는 순서는 중요하지 않습니다. 예를 들어, 아래의 두 예는 동일한 결과를 생성합니다.

spring.config.import=my.properties
my.property=value

 

my.property=value
spring.config.import=my.properties

 

위의 두 예에서 파일의 값은 가져 my.properties오기를 트리거한 파일보다 우선합니다.

단일 spring.config.import키 아래에 여러 위치를 지정할 수 있습니다. 위치는 나중에 가져오기가 우선적으로 정의된 순서대로 처리됩니다.

적절한 경우 프로필별 변형 도 가져오기에 대해 고려됩니다. 위의 예는 my.properties모든 변형뿐만 아니라 둘 다 가져옵니다 my-<profile>.properties.

Spring Boot에는 다양한 위치 주소를 지원할 수 있는 플러그형 API가 포함되어 있습니다. 기본적으로 Java 속성, YAML 및 " 구성 트리 "를 가져올 수 있습니다. 타사 jar는 추가 기술에 대한 지원을 제공할 수 있습니다(파일이 로컬이어야 한다는 요구 사항이 없음). 예를 들어 Consul, Apache ZooKeeper 또는 Netflix Archaius와 같은 외부 저장소의 구성 데이터를 상상할 수 있습니다. 자신의 위치를 ​​지원하려면 패키지 의 ConfigDataLocationResolver및 클래스를 참조하십시오 .ConfigDataLoaderorg.springframework.boot.context.config

2.3.5. 확장자 없는 파일 가져오기

일부 클라우드 플랫폼은 볼륨 마운트 파일에 파일 확장자를 추가할 수 없습니다. 이러한 확장자 없는 파일을 가져오려면 스프링 부트에 로드 방법을 알 수 있도록 힌트를 제공해야 합니다. 대괄호 안에 확장 힌트를 넣으면 됩니다.

/etc/config/myconfig예를 들어 yaml로 가져오려는 파일이 있다고 가정합니다 . application.properties다음을 사용하여 에서 가져올 수 있습니다 .

spring.config.import=file:/etc/config/myconfig[.yaml]

 

2.3.6. 구성 트리 사용

클라우드 플랫폼(예: Kubernetes)에서 애플리케이션을 실행할 때 종종 플랫폼이 제공하는 구성 값을 읽어야 합니다. 이러한 목적으로 환경 변수를 사용하는 것은 드문 일이 아니지만 특히 값을 비밀로 유지해야 하는 경우 단점이 있을 수 있습니다.

환경 변수에 대한 대안으로 이제 많은 클라우드 플랫폼에서 구성을 마운트된 데이터 볼륨에 매핑할 수 있습니다. 예를 들어 Kubernetes는 ConfigMaps및 Secrets.

사용할 수 있는 두 가지 일반적인 볼륨 탑재 패턴이 있습니다.

1. 단일 파일에는 전체 속성 집합이 포함되어 있습니다(일반적으로 YAML로 작성됨).
2. 파일 이름이 '키'가 되고 내용이 '값'이 되는 디렉토리 트리에 여러 파일이 기록됩니다.

첫 번째 경우 위에서spring.config.import 설명한 대로 YAML 또는 속성 파일을 직접 가져올 수 있습니다 . 두 번째 경우에는 Spring Boot가 모든 파일을 속성으로 노출해야 한다는 것을 알 수 있도록 접두사를 사용해야 합니다 .configtree:

예를 들어 Kubernetes가 다음 볼륨을 마운트했다고 가정해 보겠습니다.

etc/
  config/
    myapp/
      username
      password

파일 의 내용은 username구성 값이고 내용은 password비밀입니다.

이러한 속성을 가져오려면 application.properties또는 application.yaml파일에 다음을 추가할 수 있습니다.

spring.config.import=optional:configtree:/etc/config/

 

그런 다음 일반적인 방법으로 에서 속성 myapp.username에 액세스하거나 주입할 수 있습니다 .myapp.passwordEnvironment

구성 트리 아래의 폴더는 속성 이름을 형성합니다. username위의 예에서 및 로 속성에 액세스하려면 로 password설정할 수 있습니다 . spring.config.importoptional:configtree:/etc/config/myapp

점 표기법이 있는 파일 이름도 올바르게 매핑됩니다. 예를 들어 위의 예에서 이름이 myapp.usernamein인 /etc/config파일 myapp.username은 Environment.

구성 트리 값은 예상되는 내용에 따라 문자열 String과 유형 모두에 바인딩될 수 있습니다 .byte[]

동일한 상위 폴더에서 가져올 구성 트리가 여러 개인 경우 와일드카드 바로 가기를 사용할 수 있습니다. configtree:로 끝나는 모든 위치는 /*/모든 직계 자식을 구성 트리로 가져옵니다.

예를 들어 다음과 같은 볼륨이 있다고 가정합니다.

etc/
  config/
    dbconfig/
      db/
        username
        password
    mqconfig/
      mq/
        username
        password

configtree:/etc/config/*/다음을 가져오기 위치로 사용할 수 있습니다 .

spring.config.import=optional:configtree:/etc/config/*/

 

db.username이렇게 하면 , db.password및 속성 mq.username이 추가됩니다 mq.password.

와일드카드를 사용하여 로드된 디렉터리는 알파벳순으로 정렬됩니다. 다른 주문이 필요한 경우 각 위치를 별도의 가져오기로 나열해야 합니다.

구성 트리는 Docker 비밀에도 사용할 수 있습니다. Docker swarm 서비스에 비밀에 대한 액세스 권한이 부여되면 비밀이 컨테이너에 탑재됩니다. 예를 들어 이름이 지정된 비밀이 db.password위치에 마운트된 경우 다음을 사용하여 Spring 환경에서 사용할 수 /run/secrets/있도록 할 수 있습니다 .db.password

spring.config.import=optional:configtree:/run/secrets/

 

2.3.7. 속성 자리 표시자

application.properties및 의 값은 사용될 때 application.yml기존 값을 통해 필터링되므로 이전에 정의된 값(예: 시스템 속성 또는 환경 변수)을 다시 참조할 수 있습니다. Environment표준 ${name}속성 자리 표시자 구문은 값 내 어디에서나 사용할 수 있습니다. :속성 자리 표시자는 속성 이름에서 기본값을 구분하기 위해 a를 사용하여 기본값을 지정할 수도 있습니다 (예: ) ${name:default}.

기본값이 있거나 없는 자리 표시자의 사용은 다음 예에 나와 있습니다.

app.name=MyApp
app.description=${app.name} is a Spring Boot application written by ${username:Unknown}

 

username속성이 다른 곳에 설정되지 않았다고 가정하면 app.description값은 입니다 MyApp is a Spring Boot application written by Unknown.

항상 정규 형식(소문자만 사용하는 케밥-케이스)을 사용하여 자리 표시자에서 속성 이름을 참조해야 합니다. 이렇게 하면 Spring Boot가 완화된 바인딩 과 동일한 논리를 사용할 수 있습니다 @ConfigurationProperties. 예를 들어, 시스템 환경 뿐만 아니라 파일 에서도 양식을 선택 ${demo.item-price}합니다 . 대신 사용하는 경우 고려되지 않습니다 .demo.item-pricedemo.itemPriceapplication.propertiesDEMO_ITEMPRICE${demo.itemPrice}demo.item-priceDEMO_ITEMPRICE

이 기술을 사용하여 기존 Spring Boot 속성의 "짧은" 변형을 만들 수도 있습니다. 자세한 내용은 howto.html 사용법을 참조하세요 .

2.3.8. 다중 문서 파일 작업

Spring Boot를 사용하면 단일 물리적 파일을 각각 독립적으로 추가되는 여러 논리적 문서로 분할할 수 있습니다. 문서는 위에서 아래로 순서대로 처리됩니다. 이후 문서는 이전 문서에서 정의된 속성을 재정의할 수 있습니다.

파일 의 경우 application.yml표준 YAML 다중 문서 구문이 사용됩니다. 세 개의 연속 하이픈은 한 문서의 끝과 다음 문서의 시작을 나타냅니다.

예를 들어 다음 파일에는 두 개의 논리 문서가 있습니다.

spring:
  application:
    name: "MyApp"
---
spring:
  application:
    name: "MyCloudApp"
  config:
    activate:
      on-cloud-platform: "kubernetes"

 

파일 의 경우 application.properties특수 #---또는 !---주석이 문서 분할을 표시하는 데 사용됩니다.

spring.application.name=MyApp
#---
spring.application.name=MyCloudApp
spring.config.activate.on-cloud-platform=kubernetes

 

속성 파일 구분 기호에는 선행 공백이 없어야 하며 정확히 3개의 하이픈 문자가 있어야 합니다. 구분 기호 바로 앞과 뒤의 줄은 같은 주석 접두사가 아니어야 합니다.

다중 문서 속성 파일은 종종 와 같은 활성화 속성과 함께 사용됩니다 spring.config.activate.on-profile. 자세한 내용은 다음 섹션을 참조하십시오 .

다중 문서 속성 파일은 @PropertySource또는 @TestPropertySource주석을 사용하여 로드할 수 없습니다.

2.3.9. 활성화 속성

특정 조건이 충족될 때만 지정된 속성 집합을 활성화하는 것이 유용한 경우가 있습니다. 예를 들어 특정 프로필이 활성화된 경우에만 관련된 속성이 있을 수 있습니다.

를 사용하여 속성 문서를 조건부로 활성화할 수 있습니다 spring.config.activate.*.

다음 활성화 속성을 사용할 수 있습니다.

표 2. 활성화 속성재산메모

on-profile	문서가 활성화되기 위해 일치해야 하는 프로필 표현식입니다.
on-cloud-platform	CloudPlatform문서가 활성화되기 위해 감지되어야 하는 입니다 .

예를 들어 다음은 두 번째 문서가 Kubernetes에서 실행될 때만 활성화되고 "prod" 또는 "staging" 프로필이 활성화될 때만 활성화되도록 지정합니다.

myprop=always-set
#---
spring.config.activate.on-cloud-platform=kubernetes
spring.config.activate.on-profile=prod | staging
myotherprop=sometimes-set

 

2.4. 속성 암호화

Spring Boot는 속성 값 암호화에 대한 기본 제공 지원을 제공하지 않지만 Spring에 포함된 값을 수정하는 데 필요한 후크 지점을 제공합니다 Environment. 인터페이스 를 사용하면 애플리케이션이 시작되기 전에 EnvironmentPostProcessor를 조작할 수 있습니다 . 자세한 내용은 howto.html을Environment 참조하십시오 .

자격 증명과 암호를 안전하게 저장하는 방법이 필요한 경우 Spring Cloud Vault 프로젝트는 외부화된 구성을 HashiCorp Vault 에 저장하기 위한 지원을 제공합니다 .

2.5. YAML 작업

YAML 은 JSON의 상위 집합이므로 계층적 구성 데이터를 지정하기 위한 편리한 형식입니다. 이 클래스는 클래스 경로에 SnakeYAMLSpringApplication 라이브러리가 있을 때마다 자동으로 속성의 대안으로 YAML을 지원합니다 .

"Starters"를 사용하면 SnakeYAML이 에서 자동으로 제공됩니다 spring-boot-starter.

2.5.1. 속성에 YAML 매핑

YAML 문서는 계층적 형식에서 Spring과 함께 사용할 수 있는 플랫 구조로 변환해야 합니다 Environment. 예를 들어 다음 YAML 문서를 고려하십시오.

environments:
  dev:
    url: "https://dev.example.com"
    name: "Developer Setup"
  prod:
    url: "https://another.example.com"
    name: "My Cool App"

 

에서 이러한 속성에 액세스하려면 Environment다음과 같이 평면화됩니다.

environments.dev.url=https://dev.example.com
environments.dev.name=Developer Setup
environments.prod.url=https://another.example.com
environments.prod.name=My Cool App

 

마찬가지로 YAML 목록도 평면화해야 합니다. 역참조자가 있는 속성 키로 표시됩니다 [index]. 예를 들어 다음 YAML을 고려하십시오.

my:
 servers:
 - "dev.example.com"
 - "another.example.com"

 

앞의 예제는 다음 속성으로 변환됩니다.

my.servers[0]=dev.example.com
my.servers[1]=another.example.com

 

표기법을 사용하는 속성은 Spring Boot의 클래스를 사용하여 Java 또는 개체 [index]에 바인딩할 수 있습니다 . 자세한 내용은 아래의 " 유형 안전 구성 속성 " 섹션을 참조하십시오. ListSetBinder

@PropertySourceYAML 파일은 또는 주석을 사용하여 로드할 수 없습니다 @TestPropertySource. 따라서 이러한 방식으로 값을 로드해야 하는 경우 속성 파일을 사용해야 합니다.

 

2.5.2. YAML 직접 로드

Spring Framework는 YAML 문서를 로드하는 데 사용할 수 있는 두 가지 편리한 클래스를 제공합니다. YamlPropertiesFactoryBean로 YAML을 로드 하고 PropertiesYAML YamlMapFactoryBean을 Map.

YamlPropertySourceLoaderYAML을 Spring으로 로드하려는 경우 클래스를 사용할 수도 있습니다 PropertySource.

2.6. 임의 값 구성

는 RandomValuePropertySource임의 값을 주입하는 데 유용합니다(예: 비밀 또는 테스트 사례에). 다음 예제와 같이 정수, long, uuids 또는 문자열을 생성할 수 있습니다.

my.secret=${random.value}
my.number=${random.int}
my.bignumber=${random.long}
my.uuid=${random.uuid}
my.number-less-than-ten=${random.int(10)}
my.number-in-range=${random.int[1024,65536]}

 

구문 random.int*은 OPEN value (,max) CLOSE여기서 OPEN,CLOSE문자이고 정수 value,max입니다. max제공된 경우 value최소값이고 max최대값(제외)입니다.

2.7. 시스템 환경 속성 구성

Spring Boot는 환경 속성에 대한 접두사 설정을 지원합니다. 이는 구성 요구 사항이 다른 여러 Spring Boot 애플리케이션에서 시스템 환경을 공유하는 경우에 유용합니다. 시스템 환경 속성의 접두사는 에서 직접 설정할 수 있습니다 SpringApplication.

예를 들어 접두사를 로 설정하면 와 input같은 속성도 시스템 환경에서 remote.timeout와 같이 해석됩니다 .input.remote.timeout

2.8. 형식이 안전한 구성 속성

주석을 사용하여 @Value("${property}")구성 속성을 삽입하는 것은 때때로 번거로울 수 있습니다. 특히 여러 속성으로 작업하거나 데이터가 본질적으로 계층적인 경우에는 더욱 그렇습니다. Spring Boot는 강력한 형식의 빈이 애플리케이션의 구성을 관리하고 유효성을 검사할 수 있도록 하는 속성 작업의 대체 방법을 제공합니다.

유형 안전 구성 속성 간의 차이점@Value 도 참조하십시오 .

2.8.1. JavaBean 속성 바인딩

다음 예제와 같이 표준 JavaBean 속성을 선언하는 빈을 바인딩할 수 있습니다.

@ConfigurationProperties("my.service")
public class MyProperties {

    private boolean enabled;

    private InetAddress remoteAddress;

    private final Security security = new Security();

    // getters / setters...

    public static class Security {

        private String username;

        private String password;

        private List<String> roles = new ArrayList<>(Collections.singleton("USER"));

        // getters / setters...

    }

}

 

앞의 POJO는 다음 속성을 정의합니다.

• my.service.enabled, 기본값은 입니다 false.
• my.service.remote-address에서 강제할 수 있는 유형을 사용합니다 String.
• my.service.security.username, 속성 이름으로 이름이 결정되는 중첩된 "보안" 개체가 있습니다. 특히 type은 거기에서 전혀 사용되지 않으며 SecurityProperties.
• my.service.security.password.
• my.service.security.roles, 컬렉션의 String기본값은 입니다 USER.

속성 파일, YAML 파일, 환경 변수 및 기타 메커니즘을 통해 구성되는 Spring Boot에서 사용 가능한 클래스 에 매핑되는 속성은 @ConfigurationProperties공용 API이지만 클래스 자체의 접근자(getter/setter)는 직접 사용되지 않습니다. .

이러한 배열은 기본 빈 생성자에 의존하며 getter 및 setter는 일반적으로 Spring MVC에서와 같이 표준 Java Beans 속성 설명자를 통해 바인딩되기 때문에 필수입니다. 다음과 같은 경우 setter를 생략할 수 있습니다. 지도는 초기화되는 한 getter가 필요하지만 바인더에 의해 변경될 수 있으므로 setter가 반드시 필요한 것은 아닙니다. 컬렉션 및 배열은 인덱스(일반적으로 YAML 사용)를 통해 또는 쉼표로 구분된 단일 값(속성)을 사용하여 액세스할 수 있습니다. 후자의 경우 세터는 필수입니다. 이러한 유형에 대해서는 항상 setter를 추가하는 것이 좋습니다. 컬렉션을 초기화하는 경우 이전 예제에서와 같이 변경할 수 없는지 확인하십시오. 중첩된 POJO 속성이 초기화되면( Security이전 예제의 필드와 같이) setter가 필요하지 않습니다. 바인더가 기본 생성자를 사용하여 즉석에서 인스턴스를 생성하도록 하려면 setter가 필요합니다. 어떤 사람들은 Project Lombok을 사용하여 게터와 세터를 자동으로 추가합니다. 객체를 인스턴스화하기 위해 컨테이너가 자동으로 사용하므로 Lombok이 이러한 유형에 대한 특정 생성자를 생성하지 않는지 확인하십시오. 마지막으로 표준 Java Bean 속성만 고려되며 정적 속성에 대한 바인딩은 지원되지 않습니다.

2.8.2. 생성자 바인딩

이전 섹션의 예제는 다음 예제와 같이 변경할 수 없는 방식으로 다시 작성할 수 있습니다.

@ConfigurationProperties("my.service")
public class MyProperties {

    // fields...

    public MyProperties(boolean enabled, InetAddress remoteAddress, Security security) {
        this.enabled = enabled;
        this.remoteAddress = remoteAddress;
        this.security = security;
    }

    // getters...

    public static class Security {

        // fields...

        public Security(String username, String password, @DefaultValue("USER") List<String> roles) {
            this.username = username;
            this.password = password;
            this.roles = roles;
        }

        // getters...

    }

}

 

이 설정에서 단일 매개 변수화된 생성자가 있다는 것은 생성자 바인딩을 사용해야 함을 의미합니다. 이는 바인더가 바인딩하려는 매개변수가 있는 생성자를 찾을 것임을 의미합니다. 클래스에 여러 생성자가 있는 경우 @ConstructorBinding주석을 사용하여 생성자 바인딩에 사용할 생성자를 지정할 수 있습니다. 단일 매개 변수화된 생성자가 있는 클래스에 대한 생성자 바인딩을 옵트아웃하려면 생성자에 로 주석을 달아야 합니다 @Autowired. 생성자 바인딩은 레코드와 함께 사용할 수 있습니다. 레코드에 여러 생성자가 있는 경우가 아니면 를 사용할 필요가 없습니다 @ConstructorBinding.

생성자 바인딩 클래스의 중첩된 멤버(예: Security위의 예)도 해당 생성자를 통해 바인딩됩니다.

생성자 매개변수 및 레코드 구성요소를 사용하여 기본값을 지정할 수 있습니다 @DefaultValue. String주석 값을 누락된 속성의 대상 유형으로 강제 변환하기 위해 변환 서비스가 적용됩니다 .

이전 예를 참조하면 에 바인딩된 속성이 없으면 Security인스턴스 에 에 대한 값이 MyProperties포함됩니다 . 바인딩된 속성이 없는 경우에도 null이 아닌 의 인스턴스를 포함하도록 하려면 (Kotlin을 사용하는 경우 기본값이 없으므로 의 및 매개 변수를 null 허용으로 선언해야 함) 빈 주석을 사용합니다.nullsecuritySecurityusernamepasswordSecurity@DefaultValue

public MyProperties(boolean enabled, InetAddress remoteAddress, @DefaultValue Security security) {
    this.enabled = enabled;
    this.remoteAddress = remoteAddress;
    this.security = security;
}

 

@EnableConfigurationProperties생성자 바인딩을 사용하려면 구성 속성 스캔을 사용하여 클래스를 활성화해야 합니다 . 일반 Spring 메커니즘에 의해 생성된 빈(예: 메서드를 @Component사용하여 생성된 빈 @Bean또는 를 사용하여 로드된 빈 @Import) 에는 생성자 바인딩을 사용할 수 없습니다.

네이티브 이미지에서 생성자 바인딩을 사용하려면 클래스를 -parameters. Spring Boot의 Gradle 플러그인을 사용하거나 Maven 및 spring-boot-starter-parent.

java.util.Optionalwith 는 @ConfigurationProperties기본적으로 반환 유형으로 사용하기 위한 것이므로 사용하지 않는 것이 좋습니다. 따라서 구성 속성 주입에 적합하지 않습니다. 다른 유형의 속성과의 일관성을 위해 속성을 선언 Optional하고 값이 없는 경우 null비어 있는 대신 Optional바인딩됩니다.

2.8.3. @ConfigurationProperties 주석 유형 활성화

Spring Boot는 @ConfigurationProperties유형을 바인드하고 빈으로 등록하기 위한 인프라를 제공합니다. 클래스별로 구성 속성을 활성화하거나 구성 요소 검색과 유사한 방식으로 작동하는 구성 속성 검색을 활성화할 수 있습니다.

@ConfigurationProperties예를 들어 자체 자동 구성을 개발하거나 조건부로 활성화하려는 경우 주석이 달린 클래스가 검색에 적합하지 않을 수 있습니다. 이 경우 @EnableConfigurationProperties주석을 사용하여 처리할 유형 목록을 지정하십시오. @Configuration다음 예제와 같이 모든 클래스에서 이 작업을 수행할 수 있습니다 .

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(SomeProperties.class)
public class MyConfiguration {

}

 

@ConfigurationProperties("some.properties")
public class SomeProperties {

}

 

 

구성 속성 스캔을 사용하려면 @ConfigurationPropertiesScan애플리케이션에 주석을 추가하세요. 일반적으로 주석이 달린 기본 애플리케이션 클래스에 추가되지만 @SpringBootApplication모든 클래스에 추가할 수 있습니다 @Configuration. 기본적으로 주석을 선언하는 클래스의 패키지에서 스캔이 발생합니다. 검사할 특정 패키지를 정의하려는 경우 다음 예와 같이 수행할 수 있습니다.

@SpringBootApplication
@ConfigurationPropertiesScan({ "com.example.app", "com.example.another" })
public class MyApplication {

}

 

빈이 @ConfigurationProperties구성 속성 스캔을 사용하거나 를 통해 등록되면 @EnableConfigurationProperties빈의 일반적인 이름은 입니다. <prefix>-<fqn>여기서 <prefix>는 주석에 지정된 환경 키 접두어 @ConfigurationProperties이고 <fqn>빈의 정규화된 이름입니다. 어노테이션이 접두부를 제공하지 않으면 Bean의 완전한 이름만 사용됩니다. 패키지에 있다고 가정하면 위 예제 com.example.app의 빈 이름은 .SomePropertiessome.properties-com.example.app.SomeProperties

@ConfigurationProperties환경만 처리하고 특히 컨텍스트에서 다른 빈을 주입하지 않는 것이 좋습니다 . *Aware코너 케이스의 경우 setter 주입을 사용하거나 프레임워크에서 제공하는 인터페이스를 사용할 수 있습니다 (예: EnvironmentAware에 액세스해야 하는 경우 Environment). 여전히 생성자를 사용하여 다른 빈을 주입하려면 구성 속성 빈에 주석을 달고 @ComponentJavaBean 기반 속성 바인딩을 사용해야 합니다.

2.8.4. @ConfigurationProperties 주석 유형 사용

이 구성 스타일은 SpringApplication다음 예제와 같이 외부 YAML 구성에서 특히 잘 작동합니다.

my:
  service:
    remote-address: 192.168.1.1
    security:
      username: "admin"
      roles:
      - "USER"
      - "ADMIN"

 

빈 으로 작업하려면 @ConfigurationProperties다음 예제와 같이 다른 빈과 동일한 방식으로 빈을 주입할 수 있습니다.

@Service
public class MyService {

    private final MyProperties properties;

    public MyService(MyProperties properties) {
        this.properties = properties;
    }

    public void openConnection() {
        Server server = new Server(this.properties.getRemoteAddress());
        server.start();
        // ...
    }

    // ...

}

 

를 사용하면 @ConfigurationPropertiesIDE에서 자신의 키에 대한 자동 완성을 제공하는 데 사용할 수 있는 메타데이터 파일을 생성할 수도 있습니다. 자세한 내용은 부록을 참조하십시오 .

2.8.5. 타사 구성

클래스에 주석을 추가하는 데 사용할 뿐만 아니라 @ConfigurationProperties공용 메서드에서도 사용할 수 있습니다 @Bean. 이렇게 하면 제어할 수 없는 타사 구성 요소에 속성을 바인딩하려는 경우 특히 유용할 수 있습니다.

속성 에서 빈을 구성하려면 다음 예제와 같이 해당 빈 등록에 Environment추가합니다 .@ConfigurationProperties

@Configuration(proxyBeanMethods = false)
public class ThirdPartyConfiguration {

    @Bean
    @ConfigurationProperties(prefix = "another")
    public AnotherComponent anotherComponent() {
        return new AnotherComponent();
    }

}

 

접두사 로 정의된 모든 JavaBean 속성은 이전 예제와 유사한 방식으로 another해당 빈에 매핑됩니다 .AnotherComponentSomeProperties

2.8.6. Relaxed Binding

EnvironmentSpring Boot는 속성을 빈에 바인딩하기 위해 일부 완화된 규칙을 사용하므로 속성 이름과 빈 속성 이름이 @ConfigurationProperties정확히 일치할 필요가 없습니다 . Environment이것이 유용한 일반적인 예로는 대시로 구분된 환경 속성(예: context-pathbinds to contextPath) 및 대문자 환경 속성(예: PORTbinds to port)이 있습니다.

예를 들어 다음 @ConfigurationProperties클래스를 고려하십시오.

@ConfigurationProperties(prefix = "my.main-project.person")
public class MyPersonProperties {

    private String firstName;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

}

 

앞의 코드에서 다음 속성 이름을 모두 사용할 수 있습니다.

표 3. 완화된 바인딩재산메모

my.main-project.person.first-name	.properties와 파일 에 사용을 권장하는 케밥 케이스 .yml.
my.main-project.person.firstName	표준 카멜 케이스 구문.
my.main-project.person.first_name	.properties및 파일 에서 사용할 대체 형식인 밑줄 표기법 .yml.
MY_MAINPROJECT_PERSON_FIRSTNAME	시스템 환경 변수를 사용할 때 권장되는 대문자 형식입니다.

prefix주석 값은 kebab 케이스(소문자 및 와 같이 로 구분 ) 여야 합니다.-my.main-project.person

표 4. 속성 소스별 완화된 바인딩 규칙속성 소스단순한목록

속성 파일	카멜 케이스, 케밥 케이스 또는 밑줄 표기법	[ ]또는 쉼표로 구분된 값을 사용하는 표준 목록 구문
YAML 파일	카멜 케이스, 케밥 케이스 또는 밑줄 표기법	표준 YAML 목록 구문 또는 쉼표로 구분된 값
환경 변수	밑줄을 구분 기호로 사용하는 대문자 형식입니다( 환경 변수에서 바인딩 참조 ).	밑줄로 둘러싸인 숫자 값( 환경 변수에서 바인딩 참조 )
시스템 속성	카멜 케이스, 케밥 케이스 또는 밑줄 표기법	[ ]또는 쉼표로 구분된 값을 사용하는 표준 목록 구문

가능하면 속성을 와 같은 소문자 케밥 형식으로 저장하는 것이 좋습니다 my.person.first-name=Rod.

바인딩 맵

속성 에 바인딩할 때 Map원래 값이 유지되도록 특수 대괄호 표기법을 사용해야 할 수 있습니다 key. 키가 로 둘러싸여 있지 않으면 []영숫자가 아니 -거나 .제거된 모든 문자입니다.

예를 들어 다음 속성을 에 바인딩하는 것을 고려하십시오 Map<String,String>.

my.map.[/key1]=value1
my.map.[/key2]=value2
my.map./key3=value3

 

YAML 파일의 경우 키를 올바르게 구문 분석하려면 대괄호를 따옴표로 묶어야 합니다.

위 의 속성은 Mapwith /key1와 맵의 키로 바인딩됩니다 . 슬래시는 대괄호로 둘러싸이지 않았기 때문에 에서 제거되었습니다 ./key2key3key3

스칼라 값에 바인딩할 때 포함된 키는 로 .둘러쌀 필요가 없습니다 []. java.lang스칼라 값에는 를 제외한 패키지 의 열거형 및 모든 유형이 포함됩니다 Object. 에 바인딩 a.b=c하면 키 Map<String, String>를 유지 .하고 항목이 있는 맵을 반환합니다 {"a.b"="c"}. key다른 유형의 경우 가 포함된 경우 대괄호 표기법을 사용해야 합니다 .. 예를 들어 바인딩은 a.b=c항목 Map<String, Object>이 있는 맵을 반환하는 {"a"={"b"="c"}}반면 [a.b]=c항목이 있는 맵을 반환합니다 {"a.b"="c"}.

환경 변수에서 바인딩

대부분의 운영 체제는 환경 변수에 사용할 수 있는 이름에 대해 엄격한 규칙을 적용합니다. a예를 들어 Linux 셸 변수에는 문자( to z또는 Ato Z), 숫자( 0to 9) 또는 밑줄 문자( _) 만 포함될 수 있습니다 . 관례적으로 Unix 쉘 변수는 이름도 대문자로 되어 있습니다.

Spring Boot의 완화된 바인딩 규칙은 가능한 한 이러한 명명 제한과 호환되도록 설계되었습니다.

정식 형식의 속성 이름을 환경 변수 이름으로 변환하려면 다음 규칙을 따를 수 있습니다.

• .점( )을 밑줄( )로 바꿉니다 _.
• 대시( -)를 제거하십시오.
• 대문자로 변환합니다.

예를 들어 구성 속성은 spring.main.log-startup-info이라는 환경 변수입니다 SPRING_MAIN_LOGSTARTUPINFO.

개체 목록에 바인딩할 때 환경 변수를 사용할 수도 있습니다. 에 바인딩하려면 List변수 이름에서 요소 번호를 밑줄로 묶어야 합니다.

예를 들어 구성 속성은 my.service[0].other라는 환경 변수를 사용합니다 MY_SERVICE_0_OTHER.

2.8.7. 복합 유형 병합

목록이 둘 이상의 위치에 구성된 경우 재정의는 전체 목록을 대체하여 작동합니다.

예를 들어 기본적으로 및 속성이 있는 MyPojo개체를 가정합니다. 다음 예제는 에서 객체 목록을 노출합니다 .namedescriptionnullMyPojoMyProperties

@ConfigurationProperties("my")
public class MyProperties {

    private final List<MyPojo> list = new ArrayList<>();

    public List<MyPojo> getList() {
        return this.list;
    }

}

 

다음 구성을 고려하십시오.

my.list[0].name=my name
my.list[0].description=my description
#---
spring.config.activate.on-profile=dev
my.list[0].name=my another name

 

dev프로필이 활성화되지 않은 경우 이전에 정의된 대로 MyProperties.list하나의 MyPojo항목을 포함합니다. dev그러나 프로필이 활성화된 경우 에는 이름 과 설명이 있는 하나의 항목 list 만 포함됩니다 . 이 구성은 목록에 두 번째 인스턴스를 추가 하지 않으며 항목을 병합하지 않습니다.my another namenullMyPojo

여러 프로필에 a가 지정된 경우 List우선 순위가 가장 높은 프로필(해당 프로필만)이 사용됩니다. 다음 예를 고려하십시오.

my.list[0].name=my name
my.list[0].description=my description
my.list[1].name=another name
my.list[1].description=another description
#---
spring.config.activate.on-profile=dev
my.list[0].name=my another name

 

앞의 예에서 dev프로파일이 활성 이면 하나 의 항목(이름 및 설명 포함 ) 을 MyProperties.list포함합니다 . YAML의 경우 쉼표로 구분된 목록과 YAML 목록을 모두 사용하여 목록의 콘텐츠를 완전히 재정의할 수 있습니다. MyPojomy another namenull

속성 의 경우 Map여러 소스에서 가져온 속성 값으로 바인딩할 수 있습니다. 그러나 여러 소스의 동일한 속성에 대해서는 우선 순위가 가장 높은 속성이 사용됩니다. 다음 예제는 Map<String, MyPojo>from 을 노출합니다 MyProperties.

@ConfigurationProperties("my")
public class MyProperties {

    private final Map<String, MyPojo> map = new LinkedHashMap<>();

    public Map<String, MyPojo> getMap() {
        return this.map;
    }

}

 

다음 구성을 고려하십시오.

my.map.key1.name=my name 1
my.map.key1.description=my description 1
#---
spring.config.activate.on-profile=dev
my.map.key1.name=dev name 1
my.map.key2.name=dev name 2
my.map.key2.description=dev description 2

 

dev프로필이 활성화되지 않은 경우 MyProperties.map키 key1( 이름 my name 1및 설명 포함 my description 1)가 포함된 하나의 항목을 포함합니다. dev그러나 프로필이 활성화된 경우 map키 key1(이름 dev name 1및 설명 포함 my description 1) 및 key2(이름 dev name 2및 설명 포함 dev description 2)이 있는 두 개의 항목이 포함됩니다.

앞의 병합 규칙은 파일뿐만 아니라 모든 속성 소스의 속성에 적용됩니다.

2.8.8. 속성 변환

Spring Boot는 Bean에 바인딩할 때 외부 애플리케이션 속성을 올바른 유형으로 강제 변환하려고 시도합니다 @ConfigurationProperties. 사용자 지정 유형 변환이 필요한 경우 ConversionServicebean( bean 이름 지정 conversionService) 또는 사용자 지정 속성 편집기( CustomEditorConfigurerbean을 통해) 또는 사용자 지정 Converters( bean 정의에 주석이 있음 @ConfigurationPropertiesBinding)을 제공할 수 있습니다.

이 빈은 애플리케이션 수명 주기 동안 매우 초기에 요청되므로 사용 중인 종속성을 제한해야 합니다 ConversionService. 일반적으로 필요한 종속성은 생성 시 완전히 초기화되지 않을 수 있습니다. 구성 키 강제 변환에 필요 ConversionService하지 않고 @ConfigurationPropertiesBinding.

기간 변환

Spring Boot는 기간 표현을 전담 지원합니다. 속성을 노출하는 경우 java.time.Duration애플리케이션 속성에서 다음 형식을 사용할 수 있습니다.

• 일반 표현(a가 지정되지 않은 long경우 기본 단위로 밀리초 사용 )@DurationUnit
• 에서 사용하는 표준 ISO-8601 형식java.time.Duration
• 값과 단위가 결합된 더 읽기 쉬운 형식( 10s10초를 의미)

다음 예를 고려하십시오.

@ConfigurationProperties("my")
public class MyProperties {

    @DurationUnit(ChronoUnit.SECONDS)
    private Duration sessionTimeout = Duration.ofSeconds(30);

    private Duration readTimeout = Duration.ofMillis(1000);

    // getters / setters...

}

 

세션 제한 시간을 30초로 지정하려면 , 30및 PT30S모두 30s동일합니다. 500ms의 읽기 제한 시간은 다음 형식으로 지정할 수 있습니다. 500, PT0.5S및 500ms.

지원되는 모든 단위를 사용할 수도 있습니다. 이것들은:

• ns나노초 동안
• us마이크로초 동안
• ms밀리초 동안
• s초 동안
• m몇 분 동안
• h몇 시간 동안
• d몇일 동안

기본 단위는 밀리초이며 @DurationUnit위의 샘플에 표시된 대로 를 사용하여 재정의할 수 있습니다.

생성자 바인딩을 사용하려는 경우 다음 예제와 같이 동일한 속성을 노출할 수 있습니다.

@ConfigurationProperties("my")
public class MyProperties {

    // fields...

    public MyProperties(@DurationUnit(ChronoUnit.SECONDS) @DefaultValue("30s") Duration sessionTimeout,
            @DefaultValue("1000ms") Duration readTimeout) {
        this.sessionTimeout = sessionTimeout;
        this.readTimeout = readTimeout;
    }

    // getters...

}

 

속성을 업그레이드하는 경우 밀리초가 아닌 경우 Long단위를 정의해야 합니다( 사용 ). @DurationUnit이렇게 하면 훨씬 더 풍부한 형식을 지원하면서 투명한 업그레이드 경로가 제공됩니다. 기간 변환 기간 외에도 Spring Boot는 java.time.Period유형과도 작동할 수 있습니다. 애플리케이션 속성에서 다음 형식을 사용할 수 있습니다. 정규 표현(a가 지정되지 않은 int경우 일을 기본 단위로 사용 )@PeriodUnit 에서 사용하는 표준 ISO-8601 형식java.time.Period 값과 단위 쌍이 결합된 더 간단한 형식( 1y3d1년 3일을 의미)

다음 단위는 간단한 형식으로 지원됩니다.

• y수년간
• m몇 개월 동안
• w몇 주 동안
• d몇일 동안

이 java.time.Period유형은 실제로 주 수를 저장하지 않으며 "7일"을 의미하는 바로 가기입니다.

데이터 크기 변환

Spring Framework에는 DataSize크기를 바이트 단위로 표현하는 값 유형이 있습니다. 속성을 노출하는 경우 DataSize애플리케이션 속성에서 다음 형식을 사용할 수 있습니다.

• 일반 표현(a가 지정되지 long않은 경우 바이트를 기본 단위로 사용 )@DataSizeUnit
• 값과 단위가 결합된 보다 읽기 쉬운 형식( 10MB10메가바이트를 의미)

다음 예를 고려하십시오.

@ConfigurationProperties("my")
public class MyProperties {

    @DataSizeUnit(DataUnit.MEGABYTES)
    private DataSize bufferSize = DataSize.ofMegabytes(2);

    private DataSize sizeThreshold = DataSize.ofBytes(512);

    // getters/setters...

}

 

버퍼 크기를 10MB로 지정하는 것과 동일 10합니다 10MB. 256바이트의 크기 임계값은 256또는 로 지정할 수 있습니다 256B.

지원되는 모든 단위를 사용할 수도 있습니다. 이것들은:

• B바이트
• KB킬로바이트
• MB메가바이트
• GB기가바이트
• TB테라바이트

기본 단위는 바이트이며 @DataSizeUnit위의 샘플에 설명된 대로 를 사용하여 재정의할 수 있습니다.

생성자 바인딩을 사용하려는 경우 다음 예제와 같이 동일한 속성을 노출할 수 있습니다.

@ConfigurationProperties("my")
public class MyProperties {

    // fields...

    public MyProperties(@DataSizeUnit(DataUnit.MEGABYTES) @DefaultValue("2MB") DataSize bufferSize,
            @DefaultValue("512B") DataSize sizeThreshold) {
        this.bufferSize = bufferSize;
        this.sizeThreshold = sizeThreshold;
    }

    // getters...

}

 

속성을 업그레이드하는 경우 바이트가 아닌 경우 Long단위를 정의해야 합니다( 사용 ). @DataSizeUnit이렇게 하면 훨씬 더 풍부한 형식을 지원하면서 투명한 업그레이드 경로가 제공됩니다.

2.8.9. @ConfigurationProperties 유효성 검사

Spring Boot는 @ConfigurationProperties클래스에 Spring의 주석이 추가될 때마다 클래스 유효성 검사를 시도합니다 @Validated. jakarta.validation구성 클래스에서 직접 JSR-303 제약 조건 주석을 사용할 수 있습니다 . 이렇게 하려면 다음 예제와 같이 호환되는 JSR-303 구현이 클래스 경로에 있는지 확인한 다음 필드에 제약 조건 주석을 추가합니다.

@ConfigurationProperties("my.service")
@Validated
public class MyProperties {

    @NotNull
    private InetAddress remoteAddress;

    // getters/setters...

}

 

@Bean로 구성 속성을 생성하는 메서드 에 주석을 달아 유효성 검사를 트리거할 수도 있습니다 @Validated.

중첩된 속성에 대해 유효성 검사가 항상 트리거되도록 하려면 속성이 없는 경우에도 관련 필드에 로 주석을 달아야 합니다 @Valid. 다음 예제는 이전 MyProperties예제를 기반으로 합니다.

@ConfigurationProperties("my.service")
@Validated
public class MyProperties {

    @NotNull
    private InetAddress remoteAddress;

    @Valid
    private final Security security = new Security();

    // getters/setters...

    public static class Security {

        @NotEmpty
        private String username;

        // getters/setters...

    }

}

 

Validator이라는 빈 정의를 생성하여 사용자 지정 Spring을 추가할 수도 있습니다 configurationPropertiesValidator. 메서드 @Bean를 선언해야 합니다 static. 구성 속성 유효성 검사기는 애플리케이션의 수명 주기 초기에 생성되며 @Bean메서드를 정적으로 선언하면 클래스를 인스턴스화하지 않고도 빈을 생성할 수 있습니다 @Configuration. 이렇게 하면 초기 인스턴스화로 인해 발생할 수 있는 문제를 피할 수 있습니다.

모듈 spring-boot-actuator에는 모든 Bean을 노출하는 엔드포인트가 포함되어 있습니다 @ConfigurationProperties. 웹 브라우저에서 /actuator/configprops동등한 JMX 엔드포인트를 가리키거나 사용하십시오. 자세한 내용은 " 프로덕션 준비 기능 " 섹션을 참조하십시오.

2.8.10. @ConfigurationProperties 대 @Value

주석은 @Value핵심 컨테이너 기능이며 유형 안전 구성 속성과 동일한 기능을 제공하지 않습니다. 다음 표에는 @ConfigurationProperties및 에서 지원하는 기능이 요약되어 있습니다 @Value.

특징@ConfigurationProperties@Value

느슨한 바인딩	예	제한됨( 아래 참고 참조 )
메타데이터 지원	예	아니요
SpEL평가	아니요	예

를 사용하려면 @Value정식 형식(소문자만 사용하는 kebab-case)을 사용하여 속성 이름을 참조하는 것이 좋습니다. 이렇게 하면 Spring Boot가 완화된 바인딩 과 동일한 논리를 사용할 수 있습니다 @ConfigurationProperties. 예를 들어, 시스템 환경 뿐만 아니라 파일 에서도 양식을 선택 @Value("${demo.item-price}")합니다 . 대신 사용하는 경우 고려되지 않습니다 .demo.item-pricedemo.itemPriceapplication.propertiesDEMO_ITEMPRICE@Value("${demo.itemPrice}")demo.item-priceDEMO_ITEMPRICE

자신의 구성 요소에 대한 구성 키 세트를 정의하는 경우 로 주석이 달린 POJO로 그룹화하는 것이 좋습니다 @ConfigurationProperties. 이렇게 하면 자신의 빈에 주입할 수 있는 구조화되고 형식이 안전한 개체가 제공됩니다.

SpEL응용 프로그램 속성 파일 의 식은 이러한 파일을 구문 분석하고 환경을 채울 때 처리되지 않습니다. SpEL그러나 에서 표현식을 작성할 수 있습니다 @Value. 애플리케이션 속성 파일의 속성 값이 표현식인 경우 를 SpEL통해 소비될 때 평가됩니다 @Value.

3. 프로필

Spring Profiles는 애플리케이션 구성의 일부를 분리하고 특정 환경에서만 사용할 수 있도록 하는 방법을 제공합니다. 다음 예제와 같이 로드될 때 제한하기 위해 any 또는 로 @Component표시 할 수 있습니다 .@Configuration@ConfigurationProperties@Profile

@Configuration(proxyBeanMethods = false)
@Profile("production")
public class ProductionConfiguration {

    // ...

}

 

@ConfigurationProperties빈이 @EnableConfigurationProperties자동 스캔이 아닌 등록을 했다면 해당 클래스 @Profile에 주석을 지정해야 합니다 . 스캔되는 경우 클래스 자체 에 지정할 수 있습니다 . @Configuration@EnableConfigurationProperties@ConfigurationProperties@Profile@ConfigurationProperties

spring.profiles.active Environment속성을 사용하여 활성화된 프로필을 지정할 수 있습니다. 이 장의 앞부분에서 설명한 방법으로 속성을 지정할 수 있습니다. application.properties예를 들어 다음 예와 같이 에 포함할 수 있습니다 .

spring.profiles.active=dev,hsqldb

 

다음 스위치를 사용하여 명령줄에서 지정할 수도 있습니다. --spring.profiles.active=dev,hsqldb.

활성화된 프로필이 없으면 기본 프로필이 활성화됩니다. 기본 프로필의 이름은 다음 예와 같이 속성을 default사용하여 조정할 수 있습니다 .spring.profiles.default Environment

spring.profiles.default=none

 

spring.profiles.activespring.profiles.default프로필이 아닌 특정 문서에서만 사용할 수 있습니다 . 즉, 에서 활성화한 프로필 특정 파일 이나 문서 에 포함될 수 없습니다 spring.config.activate.on-profile.

예를 들어 두 번째 문서 구성이 잘못되었습니다.

# this document is valid
spring.profiles.active=prod
#---
# this document is invalid
spring.config.activate.on-profile=prod
spring.profiles.active=metrics

 

3.1. 활성 프로필 추가

이 spring.profiles.active속성은 다른 속성과 동일한 순서 규칙을 따릅니다. 가장 높은 것이 우선 PropertySource합니다. 즉, 활성 프로필을 지정한 application.properties다음 명령줄 스위치를 사용하여 바꿀 수 있습니다.

경우에 따라 활성 프로필을 대체하는 대신 추가 하는 속성이 있는 것이 유용합니다 . 속성 spring.profiles.include을 사용하여 속성에 의해 활성화된 프로필 위에 활성 프로필을 추가할 수 있습니다 spring.profiles.active. 진입 SpringApplication점에는 추가 프로필을 설정하기 위한 Java API도 있습니다. SpringApplicationsetAdditionalProfiles() 의 메소드를 참조하십시오 .

예를 들어, 다음 속성을 가진 애플리케이션이 실행되면 스위치를 사용하여 실행되는 경우에도 공통 및 로컬 프로파일이 활성화됩니다 --spring.profiles.active.

spring.profiles.include[0]=common
spring.profiles.include[1]=local

 

spring.profiles.active와 마찬가지로 spring.profiles.include프로필이 아닌 특정 문서에서만 사용할 수 있습니다. 즉, 에서 활성화한 프로필 특정 파일 이나 문서 에 포함될 수 없습니다 spring.config.activate.on-profile.

다음 섹션 에서 설명하는 프로필 그룹은 지정된 프로필이 활성화된 경우 활성 프로필을 추가하는 데 사용할 수도 있습니다.

3.2. 프로필 그룹

경우에 따라 애플리케이션에서 정의하고 사용하는 프로필이 너무 세분화되어 사용하기 번거로워질 수 있습니다. 예를 들어 데이터베이스 및 메시징 기능을 독립적으로 활성화하는 데 사용하는 프로필이 proddb있을 수 있습니다 .prodmq

이를 돕기 위해 Spring Boot에서는 프로필 그룹을 정의할 수 있습니다. 프로필 그룹을 사용하면 관련된 프로필 그룹의 논리적 이름을 정의할 수 있습니다.

예를 들어, 우리 와 프로필 production로 구성된 그룹을 만들 수 있습니다 .proddbprodmq

spring.profiles.group.production[0]=proddb
spring.profiles.group.production[1]=prodmq

 

이제 응용 프로그램을 시작하여 한 번에 , 및 프로필을 --spring.profiles.active=production활성화 할 수 있습니다.productionproddbprodmq

3.3. 프로그래밍 방식으로 프로필 설정

SpringApplication.setAdditionalProfiles(…​)애플리케이션이 실행되기 전에 호출하여 프로그래밍 방식으로 활성 프로필을 설정할 수 있습니다 . Spring의 인터페이스를 사용하여 프로필을 활성화하는 것도 가능합니다 ConfigurableEnvironment.

3.4. 프로필별 구성 파일

application.properties(또는 application.yml) 및 를 통해 참조되는 파일 의 프로필별 변형은 @ConfigurationProperties파일로 간주되어 로드됩니다. 자세한 내용은 " 프로필 특정 파일 "을 참조하십시오.

4. 로깅

Spring Boot는 모든 내부 로깅에 Commons Logging을 사용 하지만 기본 로그 구현은 열어 둡니다. Java Util 로깅 , Log4j2 및 Logback 에 대한 기본 구성이 제공됩니다 . 각각의 경우에 로거는 선택적 파일 출력과 함께 콘솔 출력을 사용하도록 사전 구성됩니다.

기본적으로 "스타터"를 사용하는 경우 로깅에 Logback이 사용됩니다. Java Util Logging, Commons Logging, Log4J 또는 SLF4J를 사용하는 종속 라이브러리가 모두 올바르게 작동하도록 적절한 Logback 라우팅도 포함됩니다.

Java에 사용할 수 있는 많은 로깅 프레임워크가 있습니다. 위의 목록이 혼란스러워 보이더라도 걱정하지 마십시오. 일반적으로 로깅 종속성을 변경할 필요가 없으며 Spring Boot 기본값이 제대로 작동합니다.

애플리케이션을 서블릿 컨테이너 또는 애플리케이션 서버에 배포할 때 Java Util Logging API로 수행된 로깅은 애플리케이션의 로그로 라우팅되지 않습니다. 이렇게 하면 컨테이너 또는 컨테이너에 배포된 다른 애플리케이션에서 수행한 로깅이 애플리케이션의 로그에 표시되지 않습니다.

4.1. 로그 형식

Spring Boot의 기본 로그 출력은 다음 예제와 유사합니다.

2023-04-20T10:07:47.363Z  INFO 18339 --- [           main] o.s.b.d.f.s.MyApplication                : Starting MyApplication using Java 17.0.6 with PID 18339 (/opt/apps/myapp.jar started by myuser in /opt/apps/)
2023-04-20T10:07:47.377Z  INFO 18339 --- [           main] o.s.b.d.f.s.MyApplication                : No active profile set, falling back to 1 default profile: "default"
2023-04-20T10:07:52.007Z  INFO 18339 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-04-20T10:07:52.064Z  INFO 18339 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-04-20T10:07:52.064Z  INFO 18339 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.8]
2023-04-20T10:07:52.577Z  INFO 18339 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2023-04-20T10:07:52.590Z  INFO 18339 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 5092 ms
2023-04-20T10:07:54.152Z  INFO 18339 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2023-04-20T10:07:54.164Z  INFO 18339 --- [           main] o.s.b.d.f.s.MyApplication                : Started MyApplication in 8.205 seconds (process running for 9.207)

다음 항목이 출력됩니다.

• 날짜 및 시간: 밀리초 정밀도로 쉽게 정렬할 수 있습니다.
• 로그 수준: ERROR, WARN, INFO, DEBUG또는 TRACE.
• 프로세스 ID.
• ---실제 로그 메시지의 시작을 구분하기 위한 구분 기호입니다 .
• 스레드 이름: 대괄호로 묶습니다(콘솔 출력의 경우 잘릴 수 있음).
• 로거 이름: 이것은 일반적으로 소스 클래스 이름입니다(종종 축약됨).
• 로그 메시지입니다.

로그백에는 레벨이 없습니다 FATAL. 에 매핑됩니다 ERROR.

4.2. 콘솔 출력

기본 로그 구성은 메시지가 기록될 때 콘솔에 메시지를 표시합니다. 기본적으로 ERROR-level, WARN-level 및 INFO-level 메시지가 기록됩니다. 플래그로 애플리케이션을 시작하여 "디버그" 모드를 활성화할 수도 있습니다 --debug.

$ java -jar myapp.jar --debug

 

debug=true에서 지정할 수도 있습니다 application.properties.

디버그 모드가 활성화되면 핵심 로거(임베디드 컨테이너, Hibernate 및 Spring Boot) 선택이 더 많은 정보를 출력하도록 구성됩니다. 디버그 모드를 활성화해도 수준이 있는 모든 메시지를 기록하도록 응용 프로그램이 구성되지 는 않습니다DEBUG .

--trace또는 플래그를 사용하여(또는 trace=true에서 application.properties) 애플리케이션을 시작하여 "추적" 모드를 활성화할 수 있습니다 . 이렇게 하면 핵심 로거(임베디드 컨테이너, Hibernate 스키마 생성 및 전체 Spring 포트폴리오) 선택에 대한 추적 로깅이 활성화됩니다.

4.2.1. 색상으로 구분된 출력

터미널이 ANSI를 지원하는 경우 가독성을 높이기 위해 컬러 출력이 사용됩니다. 지원되는 값spring.output.ansi.enabled 으로 설정하여 자동 감지를 재정의 할 수 있습니다 .

색상 코딩은 변환어를 사용하여 구성됩니다 %clr. 가장 간단한 형태에서 변환기는 다음 예제와 같이 로그 수준에 따라 출력 색상을 지정합니다.

%clr(%5p)

 

다음 표에서는 색상에 대한 로그 수준 매핑을 설명합니다.

수준색상

FATAL	빨간색
ERROR	빨간색
WARN	노란색
INFO	녹색
DEBUG	녹색
TRACE	녹색

또는 변환에 대한 옵션으로 제공하여 사용해야 하는 색상이나 스타일을 지정할 수 있습니다. 예를 들어 텍스트를 노란색으로 만들려면 다음 설정을 사용합니다.

%clr(%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}){yellow}

 

다음 색상 및 스타일이 지원됩니다.

• blue
• cyan
• faint
• green
• magenta
• red
• yellow

4.3. 파일 출력

기본적으로 Spring Boot는 콘솔에만 기록하고 로그 파일을 작성하지 않습니다. 콘솔 출력 외에 로그 파일을 작성하려면 logging.file.name또는 logging.file.path속성을 설정해야 합니다(예: 에서 application.properties).

다음 표는 logging.*속성을 함께 사용하는 방법을 보여줍니다.

표 5. 로깅 속성logging.file.namelogging.file.path예설명

(없음)	(없음)		콘솔 전용 로깅.
특정 파일	(없음)	my.log	지정된 로그 파일에 씁니다. 이름은 정확한 위치이거나 현재 디렉터리에 상대적일 수 있습니다.
(없음)	특정 디렉토리	/var/log	spring.log지정된 디렉토리에 씁니다 . 이름은 정확한 위치이거나 현재 디렉터리에 상대적일 수 있습니다.

로그 파일은 10MB에 도달하면 교체되며 콘솔 출력과 마찬가지로 ERROR-level, WARN-level 및 INFO-level 메시지가 기본적으로 기록됩니다.

로깅 속성은 실제 로깅 인프라와 독립적입니다. 결과적으로 특정 구성 키(예: logback.configurationFileLogback용)는 Spring Boot에서 관리되지 않습니다.

4.4. 파일 회전

application.propertiesLogback을 사용하는 경우 또는 파일 을 사용하여 로그 회전 설정을 미세 조정할 수 있습니다 application.yaml. 다른 모든 로깅 시스템의 경우 회전 설정을 직접 구성해야 합니다(예: Log4j2를 사용하는 경우 log4j2.xml또는 log4j2-spring.xml파일을 추가할 수 있음).

다음 순환 정책 속성이 지원됩니다.

이름설명

logging.logback.rollingpolicy.file-name-pattern	로그 아카이브를 만드는 데 사용되는 파일 이름 패턴입니다.
logging.logback.rollingpolicy.clean-history-on-start	애플리케이션이 시작될 때 로그 아카이브 정리가 발생해야 하는 경우.
logging.logback.rollingpolicy.max-file-size	아카이브되기 전 로그 파일의 최대 크기.
logging.logback.rollingpolicy.total-size-cap	로그 아카이브가 삭제되기 전에 취할 수 있는 최대 크기입니다.
logging.logback.rollingpolicy.max-history	보관할 아카이브 로그 파일의 최대 수(기본값은 7)입니다.

4.5. 로그 수준

지원되는 모든 로깅 시스템 은 TRACE, DEBUG, INFO, WARN, ERROR, FATAL 또는 OFF 중 하나를 사용 하여 Spring Environment(예: in )에서 로거 수준을 설정할 수 있습니다. 로거 는 를 사용하여 구성할 수 있습니다 .application.propertieslogging.level.<logger-name>=<level>levelrootlogging.level.root

다음 예는 에서 가능한 로깅 설정을 보여줍니다 application.properties.

logging.level.root=warn
logging.level.org.springframework.web=debug
logging.level.org.hibernate=error

 

환경 변수를 사용하여 로깅 수준을 설정할 수도 있습니다. 예를 들어 는 로 설정 LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB=DEBUG됩니다 .org.springframework.webDEBUG

위의 접근 방식은 패키지 수준 로깅에만 적용됩니다. 완화된 바인딩은 항상 환경 변수를 소문자로 변환하므로 이러한 방식으로 개별 클래스에 대한 로깅을 구성할 수 없습니다. 클래스에 대한 로깅을 구성해야 하는 경우 변수를 사용할 수 있습니다SPRING_APPLICATION_JSON .

4.6. 로그 그룹

관련 로거를 함께 그룹화하여 모두 동시에 구성할 수 있는 것이 유용한 경우가 많습니다. 예를 들어 일반적으로 모든 Tomcat 관련 로거 의 로깅 수준을 변경할 수 있지만 최상위 패키지를 쉽게 기억할 수 없습니다.

이를 돕기 위해 Spring Boot를 사용하면 Spring에서 로깅 그룹을 정의할 수 있습니다 Environment. 예를 들어 다음은 "tomcat" 그룹을 다음 항목에 추가하여 정의하는 방법입니다 application.properties.

logging.group.tomcat=org.apache.catalina,org.apache.coyote,org.apache.tomcat

 

일단 정의되면 한 줄로 그룹의 모든 로거에 대한 수준을 변경할 수 있습니다.

logging.level.tomcat=trace

 

Spring Boot에는 기본적으로 사용할 수 있는 다음과 같은 사전 정의된 로깅 그룹이 포함되어 있습니다.

이름로거

편물	org.springframework.core.codec, org.springframework.http, org.springframework.web, org.springframework.boot.actuate.endpoint.web,org.springframework.boot.web.servlet.ServletContextInitializerBeans
SQL	org.springframework.jdbc.core, org.hibernate.SQL,org.jooq.tools.LoggerListener

4.7. 로그 종료 후크 사용

애플리케이션이 종료될 때 로깅 리소스를 해제하기 위해 JVM이 종료될 때 로그 시스템 정리를 트리거하는 종료 후크가 제공됩니다. 이 종료 후크는 애플리케이션이 war 파일로 배포되지 않는 한 자동으로 등록됩니다. 애플리케이션에 복잡한 컨텍스트 계층이 있는 경우 종료 후크가 요구 사항을 충족하지 못할 수 있습니다. 그렇지 않은 경우 종료 후크를 비활성화하고 기본 로깅 시스템에서 직접 제공하는 옵션을 조사하십시오. 예를 들어 Logback은 각 로거가 자체 컨텍스트에서 생성될 수 있도록 하는 컨텍스트 선택기를 제공합니다. 이 logging.register-shutdown-hook속성을 사용하여 종료 후크를 비활성화할 수 있습니다. 로 설정하면 false등록이 비활성화됩니다. application.properties또는 파일 에서 속성을 설정할 수 있습니다 application.yaml.

logging.register-shutdown-hook=false

 

 

4.8. 사용자 지정 로그 구성

Environment다양한 로깅 시스템은 클래스 경로에 적절한 라이브러리를 포함하여 활성화할 수 있으며 클래스 경로의 루트 또는 다음 Spring 속성 으로 지정된 위치에 적절한 구성 파일을 제공하여 추가로 사용자 정의할 수 있습니다 logging.config.

시스템 속성 을 사용하여 Spring Boot가 특정 로깅 시스템을 사용하도록 강제할 수 있습니다 org.springframework.boot.logging.LoggingSystem. 값은 구현의 정규화된 클래스 이름이어야 합니다 LoggingSystem. 값을 사용하여 Spring Boot의 로깅 구성을 완전히 비활성화할 수도 있습니다 none.

로깅은 가 생성 되기 전에 초기화되므로 Spring 파일 ApplicationContext에서 로깅을 제어할 수 없습니다 . 로깅 시스템을 변경하거나 완전히 비활성화하는 유일한 방법은 시스템 속성을 통하는 것입니다. @PropertySources@Configuration

로깅 시스템에 따라 다음 파일이 로드됩니다.

로깅 시스템커스터마이징

로그백	logback-spring.xml, logback-spring.groovy, logback.xml또는logback.groovy
Log4j2	log4j2-spring.xml또는log4j2.xml
JDK(Java 유틸리티 로깅)	logging.properties

가능한 경우 로깅 구성에 변형을 사용하는 것이 좋습니다 -spring(예: logback-spring.xml대신 logback.xml). 표준 구성 위치를 사용하는 경우 Spring은 로그 초기화를 완전히 제어할 수 없습니다.

'실행 가능한 jar'에서 실행할 때 문제를 일으키는 Java Util 로깅과 관련된 알려진 클래스 로딩 문제가 있습니다. 가능한 한 '실행 가능한 jar'에서 실행할 때 이를 피하는 것이 좋습니다.

Environment사용자 지정을 돕기 위해 다음 표에 설명된 대로 몇 가지 다른 속성이 Spring에서 System 속성으로 전송됩니다 .

 

Spring 환경시스템 속성코멘트

logging.exception-conversion-word	LOG_EXCEPTION_CONVERSION_WORD	예외를 기록할 때 사용되는 변환 단어입니다.
logging.file.name	LOG_FILE	정의된 경우 기본 로그 구성에서 사용됩니다.
logging.file.path	LOG_PATH	정의된 경우 기본 로그 구성에서 사용됩니다.
logging.pattern.console	CONSOLE_LOG_PATTERN	콘솔에서 사용할 로그 패턴(stdout).
logging.pattern.dateformat	LOG_DATEFORMAT_PATTERN	로그 날짜 형식에 대한 Appender 패턴입니다.
logging.charset.console	CONSOLE_LOG_CHARSET	콘솔 로깅에 사용할 문자 집합입니다.
logging.pattern.file	FILE_LOG_PATTERN	파일에서 사용할 로그 패턴입니다( LOG_FILE활성화된 경우).
logging.charset.file	FILE_LOG_CHARSET	파일 로깅에 사용할 문자 집합입니다( LOG_FILE활성화된 경우).
logging.pattern.level	LOG_LEVEL_PATTERN	로그 수준을 렌더링할 때 사용할 형식입니다(기본값 %5p).
PID	PID	현재 프로세스 ID(가능한 경우 발견되고 아직 OS 환경 변수로 정의되지 않은 경우).

Logback을 사용하는 경우 다음 속성도 전송됩니다.

Spring 환경시스템 속성코멘트

logging.logback.rollingpolicy.file-name-pattern	LOGBACK_ROLLINGPOLICY_FILE_NAME_PATTERN	롤오버된 로그 파일 이름의 패턴(기본값 ${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz).
logging.logback.rollingpolicy.clean-history-on-start	LOGBACK_ROLLINGPOLICY_CLEAN_HISTORY_ON_START	시작 시 아카이브 로그 파일을 정리할지 여부입니다.
logging.logback.rollingpolicy.max-file-size	LOGBACK_ROLLINGPOLICY_MAX_FILE_SIZE	최대 로그 파일 크기.
logging.logback.rollingpolicy.total-size-cap	LOGBACK_ROLLINGPOLICY_TOTAL_SIZE_CAP	보관할 로그 백업의 총 크기입니다.
logging.logback.rollingpolicy.max-history	LOGBACK_ROLLINGPOLICY_MAX_HISTORY	보관할 아카이브 로그 파일의 최대 수입니다.

지원되는 모든 로깅 시스템은 구성 파일을 구문 분석할 때 시스템 속성을 참조할 수 있습니다. spring-boot.jar예제 는 기본 구성을 참조하십시오 .

• 로그백
• Log4j 2
• 자바 유틸리티 로깅

로깅 속성에서 자리 표시자를 사용하려면 기본 프레임워크의 구문이 아닌 Spring Boot의 구문을 사용해야 합니다. 특히 Logback을 사용하는 경우 :속성 이름과 기본값 사이의 구분 기호로 를 사용하고 를 사용하지 않아야 합니다 :-.

LOG_LEVEL_PATTERN만 재정의하여 (또는 logging.pattern.levelLogback과 함께) 로그 줄에 MDC 및 기타 임시 콘텐츠를 추가할 수 있습니다 . 예를 들어 를 사용하는 경우 logging.pattern.level=user:%X{user} %5p다음 예제와 같이 기본 로그 형식에 "user"에 대한 MDC 항목이 포함됩니다(있는 경우). 4.9. 로그백 확장 Spring Boot에는 고급 구성에 도움이 될 수 있는 Logback에 대한 여러 확장이 포함되어 있습니다. 구성 파일 에서 이러한 확장을 사용할 수 있습니다 logback-spring.xml.   표준 logback.xml구성 파일이 너무 일찍 로드되기 때문에 확장을 사용할 수 없습니다. logback-spring.xml속성을 사용하거나 정의 해야 합니다 logging.config.   확장은 Logback의 구성 스캔 과 함께 사용할 수 없습니다 . 그렇게 하려고 하면 구성 파일을 변경하면 다음 중 하나와 유사한 오류가 기록됩니다. ch.qos.logback.core.joran.spi.Interpreter@4 의 오류 :71ch.qos.logback.core.joran.spi.Interpreter@4 :71 의 오류 - [springProfile]에 적용할 수 있는 작업이 없습니다. 현재 ElementPath는 [[configuration][springProfile]]입니다. 4.9.1. 프로필별 구성 태그 <springProfile>를 사용하면 활성 Spring 프로필을 기반으로 구성 섹션을 선택적으로 포함하거나 제외할 수 있습니다. 프로필 섹션은 요소 내 어디에서나 지원됩니다 <configuration>. 특성을 사용하여 name구성을 허용하는 프로필을 지정합니다. 태그 <springProfile>에는 프로필 이름(예: staging) 또는 프로필 표현식이 포함될 수 있습니다. 프로필 식을 사용하면 예를 들어 보다 복잡한 프로필 논리를 표현할 수 있습니다 production & (eu-central | eu-west). 자세한 내용은 Spring Framework 참조 가이드를 확인하세요 . 다음 목록은 세 가지 샘플 프로필을 보여줍니다.

<springProfile name="staging">
    <!-- configuration to be enabled when the "staging" profile is active -->
</springProfile>

<springProfile name="dev | staging">
    <!-- configuration to be enabled when the "dev" or "staging" profiles are active -->
</springProfile>

<springProfile name="!production">
    <!-- configuration to be enabled when the "production" profile is not active -->
</springProfile>

 

4.9.2. 환경 속성

이 <springProperty>태그를 사용하면 Logback 내에서 사용하기 위해 Spring의 속성을 노출할 수 있습니다 Environment. application.properties이렇게 하면 Logback 구성에서 파일 의 값에 액세스하려는 경우 유용할 수 있습니다 . 태그는 Logback의 표준 태그와 유사한 방식으로 작동합니다 <property>. 그러나 direct 를 지정하는 대신 속성의 value를 지정합니다 source( 에서 Environment). 범위 가 아닌 다른 곳에 속성을 저장해야 하는 경우 속성을 local사용할 수 있습니다 scope. 대체 값이 필요한 경우( 속성이 에 설정되지 않은 경우 Environment) 특성을 사용할 수 있습니다 defaultValue. 다음 예에서는 Logback 내에서 사용할 속성을 노출하는 방법을 보여줍니다.

<springProperty scope="context" name="fluentHost" source="myapp.fluentd.host"
        defaultValue="localhost"/>
<appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender">
    <remoteHost>${fluentHost}</remoteHost>
    ...
</appender>

 

는 source케밥 대소문자(예: my.property-name)로 지정해야 합니다. 그러나 Environment완화된 규칙을 사용하여 속성을 에 추가할 수 있습니다.

4.10. Log4j2 확장

Spring Boot에는 고급 구성에 도움이 될 수 있는 Log4j2에 대한 여러 확장이 포함되어 있습니다. 모든 구성 파일에서 이러한 확장을 사용할 수 있습니다 log4j2-spring.xml.

표준 log4j2.xml구성 파일이 너무 일찍 로드되기 때문에 확장을 사용할 수 없습니다. log4j2-spring.xml속성을 사용하거나 정의 해야 합니다 logging.config.

확장은 Log4J에서 제공하는 Spring Boot 지원을 대체합니다. org.apache.logging.log4j:log4j-spring-boot빌드에 모듈을 포함하지 않도록 해야 합니다 .

4.10.1. 프로필별 구성

태그 <SpringProfile>를 사용하면 활성 Spring 프로필을 기반으로 구성 섹션을 선택적으로 포함하거나 제외할 수 있습니다. 프로필 섹션은 요소 내 어디에서나 지원됩니다 <Configuration>. 특성을 사용하여 name구성을 허용하는 프로필을 지정합니다. 태그 <SpringProfile>에는 프로필 이름(예: staging) 또는 프로필 표현식이 포함될 수 있습니다. 프로필 식을 사용하면 예를 들어 보다 복잡한 프로필 논리를 표현할 수 있습니다 production & (eu-central | eu-west). 자세한 내용은 Spring Framework 참조 가이드를 확인하세요 . 다음 목록은 세 가지 샘플 프로필을 보여줍니다.

<SpringProfile name="staging">
    <!-- configuration to be enabled when the "staging" profile is active -->
</SpringProfile>

<SpringProfile name="dev | staging">
    <!-- configuration to be enabled when the "dev" or "staging" profiles are active -->
</SpringProfile>

<SpringProfile name="!production">
    <!-- configuration to be enabled when the "production" profile is not active -->
</SpringProfile>

 

4.10.2. 환경 속성 조회

EnvironmentLog4j2 구성 내에서 Spring의 속성을 참조하려는 경우 spring:접두사 조회를 사용할 수 있습니다 . application.properties이렇게 하면 Log4j2 구성에서 파일 의 값에 액세스하려는 경우 유용할 수 있습니다 .

다음 예제는 Spring에서 applicationName읽는 Log4j2 속성을 설정하는 방법을 보여줍니다 .spring.application.nameEnvironment

<Properties>
    <Property name="applicationName">${spring:spring.application.name}</Property>
</Properties>

 

조회 키는 kebab 대소문자(예: my.property-name)로 지정해야 합니다.

4.10.3. Log4j2 시스템 속성

Log4j2는 다양한 항목을 구성하는 데 사용할 수 있는 여러 시스템 속성을 지원합니다. 예를 들어 log4j2.skipJansi시스템 속성을 사용하여 Windows에서 JansiConsoleAppender 출력 스트림을 사용하려고 하는지 여부를 구성할 수 있습니다 .

Log4j2 초기화 이후에 로드되는 모든 시스템 속성은 Spring에서 얻을 수 있습니다 Environment. 예를 들어 Windows에서 Jansi를 사용 하도록 파일 log4j2.skipJansi=false에 추가할 수 있습니다.application.propertiesConsoleAppender

Spring은 Environment시스템 속성 및 OS 환경 변수에 로드되는 값이 포함되지 않은 경우에만 고려됩니다.

초기 Log4j2 초기화 중에 로드된 시스템 속성은 Spring 을 참조할 수 없습니다 Environment. 예를 들어, 기본 Log4j2 구현을 선택할 수 있도록 Log4j2 속성이 사용하는 속성은 Spring 환경을 사용할 수 있기 전에 사용됩니다.

5. 국제화

Spring Boot는 지역화된 메시지를 지원하므로 애플리케이션이 다양한 언어 기본 설정을 가진 사용자에게 적합할 수 있습니다. messages기본적으로 Spring Boot는 클래스 경로의 루트에서 리소스 번들 의 존재를 찾습니다 .

messages.properties구성된 리소스 번들에 대한 기본 속성 파일을 사용할 수 있는 경우( 기본값) 자동 구성이 적용됩니다 . 리소스 번들에 언어별 속성 파일만 포함된 경우 기본값을 추가해야 합니다. 구성된 기본 이름과 일치하는 속성 파일이 없으면 자동 구성된 MessageSource.

리소스 번들의 기본 이름과 기타 여러 특성은 spring.messages다음 예제와 같이 네임스페이스를 사용하여 구성할 수 있습니다.

spring.messages.basename=messages,config.i18n.messages
spring.messages.fallback-to-system-locale=false

 

spring.messages.basename쉼표로 구분된 위치 목록(패키지 한정자 또는 클래스 경로 루트에서 확인된 리소스)을 지원합니다.

지원되는 추가 옵션은 를 참조하십시오 MessageSourceProperties.

6. JSON

Spring Boot는 세 가지 JSON 매핑 라이브러리와의 통합을 제공합니다.

• 지손
• 잭슨
• JSON-B

Jackson은 선호되는 기본 라이브러리입니다.

6.1. 잭슨

Jackson에 대한 자동 구성이 제공되며 Jackson은 spring-boot-starter-json. Jackson이 클래스 경로에 있으면 ObjectMapper빈이 자동으로 구성됩니다. 의 구성을 사용자화하기ObjectMapper 위해 몇 가지 구성 속성이 제공됩니다 .

6.1.1. 사용자 지정 직렬 변환기 및 역직렬 변환기

JsonSerializerJackson을 사용하여 JSON 데이터를 직렬화 및 역직렬화하는 경우 자체 및 클래스 를 작성할 수 있습니다 JsonDeserializer. 사용자 정의 직렬 변환기는 일반적으로 모듈을 통해 Jackson에 등록@JsonComponent 되지만 Spring Boot는 Spring Bean을 직접 등록하기 쉽게 하는 대체 주석을 제공합니다 .

또는 구현에서 주석 을 @JsonComponent직접 사용할 수 있습니다 . 다음 예제와 같이 serializer/deserializer를 내부 클래스로 포함하는 클래스에서 사용할 수도 있습니다.JsonSerializerJsonDeserializerKeyDeserializer

@JsonComponent
public class MyJsonComponent {

    public static class Serializer extends JsonSerializer<MyObject> {

        @Override
        public void serialize(MyObject value, JsonGenerator jgen, SerializerProvider serializers) throws IOException {
            jgen.writeStartObject();
            jgen.writeStringField("name", value.getName());
            jgen.writeNumberField("age", value.getAge());
            jgen.writeEndObject();
        }

    }

    public static class Deserializer extends JsonDeserializer<MyObject> {

        @Override
        public MyObject deserialize(JsonParser jsonParser, DeserializationContext ctxt) throws IOException {
            ObjectCodec codec = jsonParser.getCodec();
            JsonNode tree = codec.readTree(jsonParser);
            String name = tree.get("name").textValue();
            int age = tree.get("age").intValue();
            return new MyObject(name, age);
        }

    }

}

 

@JsonComponent의 모든 빈은 ApplicationContext자동으로 Jackson에 등록됩니다. @JsonComponent로 메타 주석이 달려 있기 때문에 @Component일반적인 구성 요소 검색 규칙이 적용됩니다.

Spring Boot는 객체를 직렬화할 때 표준 Jackson 버전에 대한 유용한 대안을 제공하는 기본 클래스 JsonObjectSerializer도 제공합니다. 자세한 내용은 Javadoc에서 및 를 JsonObjectDeserializer참조하십시오 .JsonObjectSerializerJsonObjectDeserializer

위의 예는 다음과 같이 JsonObjectSerializer/를 사용하도록 다시 작성할 수 있습니다.JsonObjectDeserializer

@JsonComponent
public class MyJsonComponent {

    public static class Serializer extends JsonObjectSerializer<MyObject> {

        @Override
        protected void serializeObject(MyObject value, JsonGenerator jgen, SerializerProvider provider)
                throws IOException {
            jgen.writeStringField("name", value.getName());
            jgen.writeNumberField("age", value.getAge());
        }

    }

    public static class Deserializer extends JsonObjectDeserializer<MyObject> {

        @Override
        protected MyObject deserializeObject(JsonParser jsonParser, DeserializationContext context, ObjectCodec codec,
                JsonNode tree) throws IOException {
            String name = nullSafeValue(tree.get("name"), String.class);
            int age = nullSafeValue(tree.get("age"), Integer.class);
            return new MyObject(name, age);
        }

    }

}

 

6.1.2. 믹스인

Jackson은 대상 클래스에 이미 선언된 주석에 추가 주석을 혼합하는 데 사용할 수 있는 믹스인을 지원합니다. Spring Boot의 Jackson 자동 구성은 주석이 달린 클래스에 대한 애플리케이션 패키지를 스캔 @JsonMixin하고 자동 구성에 등록합니다 ObjectMapper. 등록은 Spring Boot의 JsonMixinModule.

6.2. 지손

Gson에 대한 자동 구성이 제공됩니다. Gson이 클래스 경로에 있으면 Gson빈이 자동으로 구성됩니다. spring.gson.*구성을 사용자 지정하기 위해 여러 구성 속성이 제공됩니다. 더 많은 제어를 위해 하나 이상의 GsonBuilderCustomizer빈을 사용할 수 있습니다.

6.3. JSON-B

JSON-B에 대한 자동 구성이 제공됩니다. JSON-B API와 구현이 클래스 경로에 있으면 Jsonb빈이 자동으로 구성됩니다. 기본 JSON-B 구현은 종속성 관리가 제공되는 Eclipse Yasson입니다.

7. 작업 실행 및 예약

Executor컨텍스트에 빈이 없으면 Spring Boot는 비동기 작업 실행( ) 및 Spring MVC 비동기 요청 처리 ThreadPoolTaskExecutor에 자동으로 연결될 수 있는 합리적인 기본값으로 a를 자동 구성합니다.@EnableAsync

Executor컨텍스트에서 사용자 지정을 정의한 경우 일반 작업 실행(즉 @EnableAsync)은 이를 투명하게 사용하지만 Spring MVC 지원은 구현 AsyncTaskExecutor(이름 지정 applicationTaskExecutor)이 필요하므로 구성되지 않습니다. 대상 배열에 따라 Executor로 변경하거나 사용자 지정을 모두 ThreadPoolTaskExecutor정의 할 수 있습니다 .ThreadPoolTaskExecutorAsyncConfigurerExecutor 자동 구성을 사용하면 TaskExecutorBuilder자동 구성이 기본적으로 수행하는 작업을 재현하는 인스턴스를 쉽게 만들 수 있습니다.

스레드 풀은 로드에 따라 확장 및 축소할 수 있는 8개의 코어 스레드를 사용합니다. spring.task.execution이러한 기본 설정은 다음 예제와 같이 네임스페이스를 사용하여 미세 조정할 수 있습니다 .

spring.task.execution.pool.max-size=16
spring.task.execution.pool.queue-capacity=100
spring.task.execution.pool.keep-alive=10s

 

이렇게 하면 대기열이 가득 차면(작업 100개) 스레드 풀이 최대 16개 스레드로 증가하도록 제한된 대기열을 사용하도록 스레드 풀이 변경됩니다. 스레드가 10초(기본적으로 60초가 아님) 동안 유휴 상태일 때 스레드가 회수되므로 풀 축소는 더욱 공격적입니다.

예를 들어 예약된 작업 실행에 연결해야 하는 경우 A를 ThreadPoolTaskScheduler자동 구성할 수도 있습니다 . 스레드 풀은 기본적으로 하나의 스레드를 사용하며 다음 예제와 같이 네임스페이스를 @EnableScheduling사용하여 해당 설정을 미세 조정할 수 있습니다 .spring.task.scheduling

spring.task.scheduling.thread-name-prefix=scheduling-
spring.task.scheduling.pool.size=2

 

사용자 지정 실행기 또는 스케줄러를 만들어야 하는 경우 TaskExecutorBuilder빈과 빈 모두 컨텍스트에서 사용할 수 있습니다.TaskSchedulerBuilder

8. 테스트

Spring Boot는 애플리케이션을 테스트할 때 도움이 되는 여러 유틸리티와 주석을 제공합니다. spring-boot-test테스트 지원은 핵심 항목을 포함하고 spring-boot-test-autoconfigure테스트를 위한 자동 구성을 지원하는 두 가지 모듈로 제공됩니다 .

대부분의 개발자는 spring-boot-starter-testSpring Boot 테스트 모듈과 JUnit Jupiter, AssertJ, Hamcrest 및 기타 여러 유용한 라이브러리를 가져오는 "Starter"를 사용합니다.

JUnit 4를 사용하는 테스트가 있는 경우 JUnit 5의 빈티지 엔진을 사용하여 테스트를 실행할 수 있습니다. 빈티지 엔진을 사용하려면 junit-vintage-engine다음 예제와 같이 에 대한 종속성을 추가합니다.

hamcrest-coreorg.hamcrest:hamcrest에 찬성 하여 제외됩니다 spring-boot-starter-test.

8.1. 테스트 범위 종속성

" 스타터 spring-boot-starter-test"( test scope)에는 다음과 같은 제공된 라이브러리가 포함되어 있습니다.

• JUnit 5 : 단위 테스트 Java 애플리케이션을 위한 사실상의 표준입니다.
• Spring Test & Spring Boot Test: Spring Boot 애플리케이션을 위한 유틸리티 및 통합 테스트 지원.
• AssertJ : 유창한 어설션 라이브러리.
• Hamcrest : 매처 객체의 라이브러리(제약 조건 또는 조건자라고도 함).
• Mockito : 자바 모킹 프레임워크.
• JSONassert : JSON용 어설션 라이브러리입니다.
• JsonPath : JSON용 XPath.

일반적으로 이러한 공통 라이브러리는 테스트를 작성할 때 유용합니다. 이러한 라이브러리가 필요에 맞지 않으면 자체 테스트 종속성을 추가할 수 있습니다.

8.2. 스프링 애플리케이션 테스트

종속성 주입의 주요 이점 중 하나는 코드를 단위 테스트하기 쉽게 만들어야 한다는 것입니다. newSpring을 포함하지 않고도 연산자를 사용하여 개체를 인스턴스화할 수 있습니다 . 실제 종속성 대신 모의 개체를 사용할 수도 있습니다 .

종종 단위 테스트를 넘어 통합 테스트(Spring 사용 ApplicationContext)를 시작해야 합니다. 애플리케이션을 배포하거나 다른 인프라에 연결할 필요 없이 통합 테스트를 수행할 수 있으면 유용합니다.

Spring Framework에는 이러한 통합 테스트를 위한 전용 테스트 모듈이 포함되어 있습니다. org.springframework:spring-test종속성을 직접 선언하거나 "스타터" 를 사용하여 spring-boot-starter-test전이적으로 가져올 수 있습니다 .

이전에 모듈을 사용한 적이 없다면 Spring Framework 참조 문서의 관련 섹션을spring-test 읽는 것부터 시작해야 합니다 .

8.3. 스프링 부트 애플리케이션 테스트

Spring Boot 애플리케이션은 Spring이므로 ApplicationContext일반적으로 바닐라 Spring 컨텍스트로 수행하는 것 이상으로 테스트하기 위해 특별한 작업을 수행할 필요가 없습니다.

Spring Boot의 외부 속성, 로깅 및 기타 기능은 컨텍스트를 생성하는 데 사용하는 경우에만 기본적으로 컨텍스트에 설치됩니다 SpringApplication.

Spring Boot는 Spring Boot 기능이 필요할 때 @SpringBootTest표준 주석 대신 사용할 수 있는 주석을 제공합니다. spring-test @ContextConfiguration주석은 를 통해 테스트에 사용되는 을 생성하여ApplicationContextSpringApplication 작동합니다 . 애플리케이션의 보다 구체적인 조각을 테스트하기 위해 @SpringBootTest여러 가지 다른 주석도 제공됩니다 .

@RunWith(SpringRunner.class)JUnit 4를 사용하는 경우 테스트에도 추가하는 것을 잊지 마십시오 . 그렇지 않으면 주석이 무시됩니다. @ExtendWith(SpringExtension.class)JUnit 5를 사용하는 경우 등가물 을 추가할 필요가 없으며 @SpringBootTest다른 @…​Test주석에 이미 주석이 달려 있습니다.

기본적으로 @SpringBootTest서버를 시작하지 않습니다. webEnvironmentof 속성을 사용하여 @SpringBootTest테스트 실행 방법을 더 세분화 할 수 있습니다 .

• MOCK(기본값) : 웹을 불러 ApplicationContext와 모의 웹 환경을 제공합니다. 이 주석을 사용할 때 임베디드 서버가 시작되지 않습니다. 클래스 경로에서 웹 환경을 사용할 수 없는 경우 이 모드는 일반 비웹 생성으로 투명하게 돌아갑니다 ApplicationContext. 웹 애플리케이션의 모의 기반 테스트 와 함께 @AutoConfigureMockMvc또는 이를 위해 사용할 수 있습니다.@AutoConfigureWebTestClient
• RANDOM_PORT: 를 불러 WebServerApplicationContext와 실제 웹 환경을 제공합니다. 임베디드 서버가 시작되고 임의의 포트에서 청취합니다.
• DEFINED_PORT: 를 불러 WebServerApplicationContext와 실제 웹 환경을 제공합니다. 포함된 서버가 시작되고 정의된 포트( 에서 application.properties) 또는 기본 포트에서 수신 대기합니다 8080.
• NONE: 를 ApplicationContext사용하여 로드하지만 웹SpringApplication 환경(모의 또는 기타)을 제공하지 않습니다 .

테스트가 인 경우 @Transactional기본적으로 각 테스트 방법이 끝날 때 트랜잭션을 롤백합니다. 그러나 이 배열을 함께 사용하거나 RANDOM_PORT묵시적 DEFINED_PORT으로 실제 서블릿 환경을 제공하므로 HTTP 클라이언트와 서버는 별도의 스레드에서 실행되므로 별도의 트랜잭션에서 실행됩니다. 이 경우 서버에서 시작된 트랜잭션은 롤백되지 않습니다.

@SpringBootTest또한 webEnvironment = WebEnvironment.RANDOM_PORT응용 프로그램이 관리 서버에 대해 다른 포트를 사용하는 경우 별도의 임의 포트에서 관리 서버를 시작합니다.

8.3.1. 웹 애플리케이션 유형 감지

Spring MVC를 사용할 수 있는 경우 일반 MVC 기반 애플리케이션 컨텍스트가 구성됩니다. Spring WebFlux만 있는 경우 이를 감지하고 대신 WebFlux 기반 애플리케이션 컨텍스트를 구성합니다.

둘 다 있으면 Spring MVC가 우선합니다. 이 시나리오에서 반응형 웹 애플리케이션을 테스트하려면 속성을 설정해야 합니다 spring.main.web-application-type.

@SpringBootTest(properties = "spring.main.web-application-type=reactive")
class MyWebFluxTests {

    // ...

}

 

8.3.2. 테스트 구성 감지

Spring Test Framework에 익숙한 경우 로드할 @ContextConfiguration(classes=…​)Spring을 지정하기 위해 사용하는 데 익숙할 수 있습니다. @Configuration또는 @Configuration테스트 내에서 중첩 클래스를 자주 사용했을 수 있습니다.

Spring Boot 애플리케이션을 테스트할 때 이는 종종 필요하지 않습니다. Spring Boot의 @*Test주석은 기본 구성을 명시적으로 정의하지 않을 때마다 자동으로 기본 구성을 검색합니다.

@SpringBootApplication검색 알고리즘은 또는 로 주석이 달린 클래스를 찾을 때까지 테스트를 포함하는 패키지에서 작동합니다 @SpringBootConfiguration. 코드를 합리적인 방식으로 구조화했다면 일반적으로 기본 구성을 찾을 수 있습니다 .

테스트 주석을 사용하여 응용 프로그램의 보다 구체적인 부분을 테스트하는 경우 기본 메서드의 응용 프로그램 클래스 의 특정 영역에 특정한 구성 설정을 추가하지 않아야 합니다 . 기본 구성 요소 스캔 구성은 @SpringBootApplication슬라이싱이 예상대로 작동하는지 확인하는 데 사용되는 제외 필터를 정의합니다. @ComponentScan-annotated 클래스 에서 명시적 지시문을 사용하는 경우 @SpringBootApplication해당 필터가 비활성화된다는 점에 유의하십시오. 슬라이싱을 사용하는 경우 다시 정의해야 합니다.

기본 구성을 사용자 지정하려는 경우 중첩 @TestConfiguration클래스를 사용할 수 있습니다. @Configuration애플리케이션의 기본 구성 대신 사용되는 중첩 클래스와 달리 중첩 @TestConfiguration클래스는 애플리케이션의 기본 구성 외에 사용됩니다.

Spring의 테스트 프레임워크는 테스트 간에 애플리케이션 컨텍스트를 캐시합니다. 따라서 테스트가 동일한 구성을 공유하는 한(검색 방법에 관계없이) 잠재적으로 시간이 많이 소요되는 컨텍스트 로드 프로세스는 한 번만 발생합니다.

8.3.3. 테스트 구성 기본 방법 사용

일반적으로 에서 검색한 테스트 구성이 @SpringBootTest기본 @SpringBootApplication. main잘 구조화된 대부분의 응용 프로그램에서 이 구성 클래스에는 응용 프로그램을 시작하는 데 사용되는 메서드 도 포함됩니다 .

예를 들어 다음은 일반적인 Spring Boot 애플리케이션에 대한 매우 일반적인 코드 패턴입니다.

@SpringBootApplication
public class MyApplication {

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

}

 

위의 예에서 main메서드는 에 위임하는 것 외에는 아무 작업도 수행하지 않습니다 SpringApplication.run. main그러나 를 호출하기 전에 사용자 정의를 적용하는 더 복잡한 메서드를 가질 수 있습니다 SpringApplication.run.

예를 들어 다음은 배너 모드를 변경하고 추가 프로필을 설정하는 애플리케이션입니다.

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(MyApplication.class);
        application.setBannerMode(Banner.Mode.OFF);
        application.setAdditionalProfiles("myprofile");
        application.run(args);
    }

}

 

메서드 의 사용자 지정은 main결과에 영향을 줄 수 있으므로 메서드를 사용하여 테스트에 사용되는 를 생성 ApplicationContext할 수도 있습니다 . 기본적으로 메서드를 호출하지 않고 대신 클래스 자체를 직접 사용하여mainApplicationContext@SpringBootTestmainApplicationContext

이 동작을 변경하려면 useMainMethod의 속성을 또는 @SpringBootTest로 변경할 수 있습니다 . 로 설정하면 메서드를 찾을 수 없으면 테스트가 실패합니다 . 로 설정하면 사용 가능한 경우 방법 이 사용되고 그렇지 않으면 표준 로드 메커니즘이 사용됩니다.UseMainMethod.ALWAYSUseMainMethod.WHEN_AVAILABLEALWAYSmainWHEN_AVAILABLEmain

예를 들어 다음 테스트는 를 만들기 위해 main메서드를 호출합니다 . 기본 메서드가 추가 프로필을 설정하면 시작할 때 해당 프로필이 활성화됩니다 .MyApplicationApplicationContextApplicationContext

@SpringBootTest(useMainMethod = UseMainMethod.ALWAYS)
class MyApplicationTests {

    @Test
    void exampleTest() {
        // ...
    }

}

 

8.3.4. 테스트 구성 제외

@SpringBootApplication애플리케이션에서 구성 요소 검색을 사용하는 경우(예: 또는 를 사용하는 경우 @ComponentScan) 특정 테스트에 대해서만 만든 최상위 구성 클래스가 실수로 모든 곳에서 선택되는 것을 볼 수 있습니다.

앞에서 본 것처럼 @TestConfiguration기본 구성을 사용자 정의하기 위해 테스트의 내부 클래스에서 사용할 수 있습니다 . 최상위 클래스에 배치되면 스캔을 통해 @TestConfiguration클래스를 src/test/java선택하지 않아야 함을 나타냅니다. 그런 다음 다음 예제와 같이 필요한 위치에서 해당 클래스를 명시적으로 가져올 수 있습니다.

@SpringBootTest
@Import(MyTestsConfiguration.class)
class MyTests {

    @Test
    void exampleTest() {
        // ...
    }

}

 

직접 사용하는 경우 @ComponentScan(즉, 를 통하지 않고 @SpringBootApplication) 를 등록해야 합니다 TypeExcludeFilter. 자세한 내용은 Javadoc을 참조하십시오 .

8.3.5. 애플리케이션 인수 사용

애플리케이션에 인수가@SpringBootTest 필요한 경우 특성을 사용하여 인수를 주입 할 수 있습니다 args.

@SpringBootTest(args = "--app.test=one")
class MyApplicationArgumentTests {

    @Test
    void applicationArgumentsPopulated(@Autowired ApplicationArguments args) {
        assertThat(args.getOptionNames()).containsOnly("app.test");
        assertThat(args.getOptionValues("app.test")).containsOnly("one");
    }

}

 

8.3.6. 모의 환경으로 테스트

기본적으로 @SpringBootTest서버를 시작하지 않고 대신 웹 끝점 테스트를 위한 모의 환경을 설정합니다.

Spring MVC를 사용하면 다음 예제와 같이 MockMvc또는 를 사용하여 웹 엔드포인트를 쿼리할 수 있습니다 .WebTestClient

@SpringBootTest
@AutoConfigureMockMvc
class MyMockMvcTests {

    @Test
    void testWithMockMvc(@Autowired MockMvc mvc) throws Exception {
        mvc.perform(get("/")).andExpect(status().isOk()).andExpect(content().string("Hello World"));
    }

    // If Spring WebFlux is on the classpath, you can drive MVC tests with a WebTestClient
    @Test
    void testWithWebTestClient(@Autowired WebTestClient webClient) {
        webClient
                .get().uri("/")
                .exchange()
                .expectStatus().isOk()
                .expectBody(String.class).isEqualTo("Hello World");
    }

}

 

웹 레이어에만 집중하고 전체를 시작하지 않으려면 대신 사용하는ApplicationContext 것이 좋습니다 . @WebMvcTest

WebTestClientSpring WebFlux 끝점을 사용하면 다음 예제와 같이 사용할 수 있습니다 .

@SpringBootTest
@AutoConfigureWebTestClient
class MyMockWebTestClientTests {

    @Test
    void exampleTest(@Autowired WebTestClient webClient) {
        webClient
            .get().uri("/")
            .exchange()
            .expectStatus().isOk()
            .expectBody(String.class).isEqualTo("Hello World");
    }

}

 

모의 환경 내에서 테스트하는 것이 일반적으로 전체 서블릿 컨테이너로 실행하는 것보다 빠릅니다. 그러나 모킹은 Spring MVC 레이어에서 발생하기 때문에 하위 수준의 서블릿 컨테이너 동작에 의존하는 코드는 MockMvc로 직접 테스트할 수 없습니다. 예를 들어 Spring Boot의 오류 처리는 서블릿 컨테이너에서 제공하는 "오류 페이지" 지원을 기반으로 합니다. 즉, MVC 레이어가 예상대로 예외를 발생시키고 처리하는지 테스트할 수 있지만 특정 사용자 지정 오류 페이지가 렌더링되는지 직접 테스트할 수는 없습니다. 이러한 하위 수준 문제를 테스트해야 하는 경우 다음 섹션에 설명된 대로 완전히 실행 중인 서버를 시작할 수 있습니다.

8.3.7. 실행 중인 서버로 테스트

전체 실행 서버를 시작해야 하는 경우 임의 포트를 사용하는 것이 좋습니다. 를 사용하면 @SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)테스트가 실행될 때마다 사용 가능한 포트가 임의로 선택됩니다.

주석 을 사용하여 테스트에 사용된 실제 포트를 삽입@LocalServerPort 할 수 있습니다 . 편의를 위해 시작된 서버에 대한 REST 호출을 수행해야 하는 테스트는 다음 예제와 같이 실행 중인 서버에 대한 상대 링크를 확인하고 응답 확인을 위한 전용 API와 함께 제공되는 를 추가 로 사용할 수 있습니다.@AutowireWebTestClient

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class MyRandomPortWebTestClientTests {

    @Test
    void exampleTest(@Autowired WebTestClient webClient) {
        webClient
            .get().uri("/")
            .exchange()
            .expectStatus().isOk()
            .expectBody(String.class).isEqualTo("Hello World");
    }

}

 

WebTestClient라이브 서버와 모의 환경 모두에 사용할 수 있습니다 .

이 설정은 spring-webflux클래스 경로에 필요합니다. webflux를 추가할 수 없거나 추가하지 않을 경우 Spring Boot는 다음과 같은 TestRestTemplate기능도 제공합니다.

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class MyRandomPortTestRestTemplateTests {

    @Test
    void exampleTest(@Autowired TestRestTemplate restTemplate) {
        String body = restTemplate.getForObject("/", String.class);
        assertThat(body).isEqualTo("Hello World");
    }

}

 

8.3.8. WebTestClient 사용자 지정

bean을 사용자 정의하려면 bean을 WebTestClient구성하십시오 WebTestClientBuilderCustomizer. 이러한 빈은 WebTestClient.Builder를 생성하는 데 사용되는 로 호출됩니다 WebTestClient.

8.3.9. JMX 사용

테스트 컨텍스트 프레임워크가 컨텍스트를 캐시하므로 동일한 구성 요소가 동일한 도메인에 등록되는 것을 방지하기 위해 JMX는 기본적으로 비활성화되어 있습니다. 이러한 테스트가 에 액세스해야 하는 경우 MBeanServer더티로 표시하는 것도 고려하십시오.

@SpringBootTest(properties = "spring.jmx.enabled=true")
@DirtiesContext
class MyJmxTests {

    @Autowired
    private MBeanServer mBeanServer;

    @Test
    void exampleTest() {
        assertThat(this.mBeanServer.getDomains()).contains("java.lang");
        // ...
    }

}

 

8.3.10. 지표 사용

클래스 경로에 관계없이 인메모리 백업을 제외한 측정기 레지스트리는 @SpringBootTest.

통합 테스트의 일부로 메트릭을 다른 백엔드로 내보내야 하는 경우 @AutoConfigureObservability.

8.3.11. 추적 사용

클래스 경로에 관계없이 .NET을 사용할 때 추적이 자동으로 구성되지 않습니다 @SpringBootTest.

통합 테스트의 일부로 추적이 필요한 경우 @AutoConfigureObservability.

8.3.12. 모킹 및 스파이 콩

테스트를 실행할 때 애플리케이션 컨텍스트 내에서 특정 구성 요소를 조롱해야 하는 경우가 있습니다. 예를 들어, 개발 중에 사용할 수 없는 일부 원격 서비스에 대한 퍼사드가 있을 수 있습니다. 모의는 실제 환경에서 트리거하기 어려울 수 있는 오류를 시뮬레이션하려는 경우에도 유용할 수 있습니다.

Spring Boot @MockBean에는 ApplicationContext. 주석을 사용하여 새 bean을 추가하거나 단일 기존 bean 정의를 바꿀 수 있습니다. 주석은 테스트 클래스, 테스트 내의 필드 또는 @Configuration클래스와 필드에서 직접 사용할 수 있습니다. 필드에서 사용하면 생성된 모의 인스턴스도 주입됩니다. 모의 콩은 각 테스트 방법 후에 자동으로 재설정됩니다.

테스트에서 Spring Boot의 테스트 주석(예: @SpringBootTest) 중 하나를 사용하는 경우 이 기능이 자동으로 활성화됩니다. 다른 배열로 이 기능을 사용하려면 다음 예와 같이 리스너를 명시적으로 추가해야 합니다.

다음 예제는 기존 RemoteService빈을 모의 구현으로 대체합니다.

@SpringBootTest
class MyTests {

    @Autowired
    private Reverser reverser;

    @MockBean
    private RemoteService remoteService;

    @Test
    void exampleTest() {
        given(this.remoteService.getValue()).willReturn("spring");
        String reverse = this.reverser.getReverseValue(); // Calls injected RemoteService
        assertThat(reverse).isEqualTo("gnirps");
    }

}

 

@MockBean애플리케이션 컨텍스트 새로 고침 중에 실행되는 Bean의 동작을 조롱하는 데 사용할 수 없습니다. 테스트가 실행될 때까지 애플리케이션 컨텍스트 새로 고침이 완료되고 모의 동작을 구성하기에는 너무 늦었습니다. @Bean이 상황에서 모의를 만들고 구성하는 방법을 사용하는 것이 좋습니다 .

@SpyBean또한 기존 빈을 Mockito로 래핑하는 데 사용할 수 있습니다 spy. 자세한 내용은 Javadoc을 참조하십시오 .

범위가 지정된 Bean에 대해 생성된 것과 같은 CGLib 프록시는 프록시된 메서드를 final. final이렇게 하면 Mockito가 기본 구성에서 메서드를 모의하거나 감시할 수 없으므로 올바르게 작동하지 않습니다 . 이러한 bean을 모의하거나 감시하려면 org.mockito:mockito-inline애플리케이션의 테스트 종속성을 추가하여 인라인 모의 작성기를 사용하도록 Mockito를 구성하십시오. 이를 통해 Mockito는 메서드를 조롱하고 감시할 수 있습니다 final.

Spring의 테스트 프레임워크는 테스트 간에 애플리케이션 컨텍스트를 캐시하고 동일한 구성을 공유하는 테스트를 위해 컨텍스트를 재사용하지만 캐시 키를 사용하거나 @MockBean캐시 @SpyBean키에 영향을 미치므로 컨텍스트 수가 증가할 가능성이 높습니다.

@SpyBean이름으로 매개변수를 참조하는 메소드 로 bean을 감시하는 데 를 사용하는 경우 @Cacheable애플리케이션을 로 컴파일해야 합니다 -parameters. 이렇게 하면 bean이 염탐되면 캐싱 인프라에서 매개변수 이름을 사용할 수 있습니다.

Spring에 의해 프록시되는 bean을 감시하기 위해 를 사용하는 경우 , 예를 들어 또는 를 @SpyBean사용하여 기대치를 설정할 때와 같은 일부 상황에서 Spring의 프록시를 제거해야 할 수 있습니다 . 그렇게 하는 데 사용합니다 .givenwhenAopTestUtils.getTargetObject(yourProxiedSpy)

8.3.13. 자동 구성된 테스트

Spring Boot의 자동 구성 시스템은 애플리케이션에서 잘 작동하지만 때때로 테스트에는 너무 많을 수 있습니다. 애플리케이션의 "조각"을 테스트하는 데 필요한 구성 부분만 로드하는 것이 도움이 되는 경우가 많습니다. 예를 들어 Spring MVC 컨트롤러가 URL을 올바르게 매핑하고 있는지 테스트하고 이러한 테스트에 데이터베이스 호출을 포함하고 싶지 않거나 JPA 엔터티를 테스트하고 싶은데 웹 레이어에 관심이 없을 수 있습니다. 테스트가 실행됩니다.

이 spring-boot-test-autoconfigure모듈에는 이러한 "슬라이스"를 자동으로 구성하는 데 사용할 수 있는 여러 주석이 포함되어 있습니다. 각각은 유사한 방식으로 작동하여 자동 구성 설정을 사용자 지정하는 데 사용할 수 있는 하나 이상의 주석을 @…​Test로드하는 주석을 제공합니다.ApplicationContext@AutoConfigure…​

각 슬라이스는 구성 요소 스캔을 적절한 구성 요소로 제한하고 매우 제한된 자동 구성 클래스 집합을 로드합니다. 그 중 하나를 제외해야 하는 경우 대부분의 @…​Test주석은 excludeAutoConfiguration속성을 제공합니다. 또는 를 사용할 수 있습니다 @ImportAutoConfiguration#exclude.

하나의 테스트에서 여러 @…​Test주석을 사용하여 여러 "조각"을 포함하는 것은 지원되지 않습니다. 여러 "슬라이스"가 필요한 경우 주석 중 하나를 선택 하고 다른 "슬라이스"의 주석을 직접 @…​Test포함합니다 .@AutoConfigure…​

@AutoConfigure…​표준 주석과 함께 주석을 사용할 수도 있습니다 @SpringBootTest. 애플리케이션을 "슬라이싱"하는 데는 관심이 없지만 일부 자동 구성된 테스트 빈을 원하는 경우 이 조합을 사용할 수 있습니다.

8.3.14. 자동 구성된 JSON 테스트

개체 JSON 직렬화 및 역직렬화가 예상대로 작동하는지 테스트하기 위해 주석을 사용할 수 있습니다 @JsonTest. @JsonTest다음 라이브러리 중 하나일 수 있는 사용 가능한 지원 JSON 매퍼를 자동 구성합니다.

• Jackson ObjectMapper, 모든 @JsonComponent콩 및 모든 Jackson Modules
• Gson
• Jsonb

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@JsonTest 수 있습니다 .

자동 구성 요소를 구성해야 하는 경우 @AutoConfigureJsonTesters주석을 사용할 수 있습니다.

Spring Boot에는 JSONAssert 및 JsonPath 라이브러리와 함께 작동하여 JSON이 예상대로 표시되는지 확인하는 AssertJ 기반 도우미가 포함되어 있습니다. , , 및 클래스는 각각 Jackson, Gson, Jsonb 및 Strings JacksonTester에 사용할 수 있습니다. 테스트 클래스의 모든 도우미 필드 는 . 다음 예는 Jackson의 테스트 클래스를 보여줍니다.GsonTesterJsonbTesterBasicJsonTester@Autowired@JsonTest

@JsonTest
class MyJsonTests {

    @Autowired
    private JacksonTester<VehicleDetails> json;

    @Test
    void serialize() throws Exception {
        VehicleDetails details = new VehicleDetails("Honda", "Civic");
        // Assert against a `.json` file in the same package as the test
        assertThat(this.json.write(details)).isEqualToJson("expected.json");
        // Or use JSON path based assertions
        assertThat(this.json.write(details)).hasJsonPathStringValue("@.make");
        assertThat(this.json.write(details)).extractingJsonPathStringValue("@.make").isEqualTo("Honda");
    }

    @Test
    void deserialize() throws Exception {
        String content = "{\"make\":\"Ford\",\"model\":\"Focus\"}";
        assertThat(this.json.parse(content)).isEqualTo(new VehicleDetails("Ford", "Focus"));
        assertThat(this.json.parseObject(content).getMake()).isEqualTo("Ford");
    }

}

 

JSON 도우미 클래스는 표준 단위 테스트에서 직접 사용할 수도 있습니다. 이렇게 하려면 를 사용하지 않는 경우 메소드 initFields에서 헬퍼의 메소드를 호출하십시오 . @Before@JsonTest

isEqualToSpring Boot의 AssertJ 기반 헬퍼를 사용하여 주어진 JSON 경로에서 숫자 값을 어설션하는 경우 유형에 따라 사용하지 못할 수 있습니다 . 대신 AssertJ를 사용하여 satisfies값이 주어진 조건과 일치하는지 확인할 수 있습니다. 예를 들어, 다음 예제는 실제 숫자가 의 0.15오프셋 내 에서 가까운 float 값이라고 주장합니다 0.01.

@Test
void someTest() throws Exception {
    SomeObject value = new SomeObject(0.152f);
    assertThat(this.json.write(value)).extractingJsonPathNumberValue("@.test.numberValue")
        .satisfies((number) -> assertThat(number.floatValue()).isCloseTo(0.15f, within(0.01f)));
}

 

8.3.15. 자동 구성된 Spring MVC 테스트

Spring MVC 컨트롤러가 예상대로 작동하는지 테스트하려면 @WebMvcTest주석을 사용하십시오. Spring MVC 인프라 를 @WebMvcTest자동 구성하고 검색된 빈을 @Controller, @ControllerAdvice, @JsonComponent, Converter, GenericConverter, , , 및 로 제한합니다 . 주석이 사용될 때 일반 및 콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .FilterHandlerInterceptorWebMvcConfigurerWebMvcRegistrationsHandlerMethodArgumentResolver@Component@ConfigurationProperties@WebMvcTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@WebMvcTest 수 있습니다 .

Jackson 과 같은 추가 구성 요소를 등록해야 하는 경우 테스트에서 를 Module사용하여 추가 구성 클래스를 가져올 수 있습니다 .@Import

종종 @WebMvcTest단일 컨트롤러로 제한되며 필요한 협력자에게 모의 구현을 제공하기 위해 와 함께 사용됩니다 @MockBean.

@WebMvcTest또한 자동 구성 MockMvc. Mock MVC는 전체 HTTP 서버를 시작할 필요 없이 MVC 컨트롤러를 빠르게 테스트할 수 있는 강력한 방법을 제공합니다.

로 주석을 달아 MockMvc비 @WebMvcTest(예: )에서 자동 구성할 수도 있습니다 . 다음 예제에서는 다음을 사용합니다 . @SpringBootTest@AutoConfigureMockMvcMockMvc

@WebMvcTest(UserVehicleController.class)
class MyControllerTests {

    @Autowired
    private MockMvc mvc;

    @MockBean
    private UserVehicleService userVehicleService;

    @Test
    void testExample() throws Exception {
        given(this.userVehicleService.getVehicleDetails("sboot"))
            .willReturn(new VehicleDetails("Honda", "Civic"));
        this.mvc.perform(get("/sboot/vehicle").accept(MediaType.TEXT_PLAIN))
            .andExpect(status().isOk())
            .andExpect(content().string("Honda Civic"));
    }

}

 

자동 구성 요소를 구성해야 하는 경우(예: 서블릿 필터를 적용해야 하는 경우) 주석에서 속성을 사용할 수 있습니다 @AutoConfigureMockMvc.

HtmlUnit 및 Selenium을 사용하는 경우 자동 구성은 HtmlUnit WebClient빈 및/또는 Selenium WebDriver빈도 제공합니다. 다음 예제에서는 HtmlUnit을 사용합니다.

@WebMvcTest(UserVehicleController.class)
class MyHtmlUnitTests {

    @Autowired
    private WebClient webClient;

    @MockBean
    private UserVehicleService userVehicleService;

    @Test
    void testExample() throws Exception {
        given(this.userVehicleService.getVehicleDetails("sboot")).willReturn(new VehicleDetails("Honda", "Civic"));
        HtmlPage page = this.webClient.getPage("/sboot/vehicle.html");
        assertThat(page.getBody().getTextContent()).isEqualTo("Honda Civic");
    }

}

 

기본적으로 Spring Boot는 WebDriver각 테스트 후에 드라이버가 종료되고 새 인스턴스가 주입되도록 하기 위해 bean을 특별한 "범위"에 넣습니다. 이 동작을 원하지 않으면 정의 @Scope("singleton")에 추가할 수 있습니다 WebDriver @Bean.

Spring Boot에 의해 생성된 범위 webDriver는 동일한 이름의 사용자 정의 범위를 대체합니다. 자신의 범위를 정의하면 를 webDriver사용할 때 작동이 중지될 수 있습니다 @WebMvcTest.

클래스 경로에 Spring Security가 있는 경우 Bean @WebMvcTest도 스캔합니다 WebSecurityConfigurer. 이러한 테스트에 대해 보안을 완전히 비활성화하는 대신 Spring Security의 테스트 지원을 사용할 수 있습니다. Spring Security의 지원을 사용하는 방법에 대한 자세한 내용은 이 howto.html 방법 섹션 MockMvc에서 찾을 수 있습니다 .

때때로 Spring MVC 테스트를 작성하는 것만으로는 충분하지 않습니다. Spring Boot는 실제 서버에서 전체 종단 간 테스트를 실행할 수 있도록 도와줍니다 .

8.3.16. 자동 구성된 Spring WebFlux 테스트

Spring WebFlux 컨트롤러가 예상대로 작동하는지 테스트하려면 주석을 사용할 수 있습니다 @WebFluxTest. @WebFluxTestSpring WebFlux 인프라를 자동 구성하고 스캔된 빈을 @Controller, @ControllerAdvice, @JsonComponent, Converter, GenericConverter, WebFilter및 로 제한합니다 WebFluxConfigurer. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@WebFluxTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@WebFluxTest 수 있습니다 .

Jackson 과 같은 추가 구성 요소를 등록해야 하는 경우 테스트에서 를 Module사용하여 추가 구성 클래스를 가져올 수 있습니다 .@Import

종종 @WebFluxTest단일 컨트롤러로 제한되며 필요한 협력자에게 모의 구현을 제공하기 위해 주석과 함께 사용됩니다 @MockBean.

@WebFluxTestWebTestClient또한 전체 HTTP 서버를 시작할 필요 없이 WebFlux 컨트롤러를 빠르게 테스트할 수 있는 강력한 방법을 제공하는 자동 구성도 제공합니다.

로 주석을 달아 WebTestClient비 @WebFluxTest(예: )에서 자동 구성할 수도 있습니다 . 다음 예제는 와 a 를 모두 사용하는 클래스를 보여줍니다 . @SpringBootTest@AutoConfigureWebTestClient@WebFluxTestWebTestClient

@WebFluxTest(UserVehicleController.class)
class MyControllerTests {

    @Autowired
    private WebTestClient webClient;

    @MockBean
    private UserVehicleService userVehicleService;

    @Test
    void testExample() {
        given(this.userVehicleService.getVehicleDetails("sboot"))
            .willReturn(new VehicleDetails("Honda", "Civic"));
        this.webClient.get().uri("/sboot/vehicle").accept(MediaType.TEXT_PLAIN).exchange()
            .expectStatus().isOk()
            .expectBody(String.class).isEqualTo("Honda Civic");
    }

}

 

WebTestClient이 설정은 모의 웹 애플리케이션에서 사용하는 것이 현재 WebFlux에서만 작동하므로 WebFlux 애플리케이션에서만 지원됩니다 .

@WebFluxTest기능적 웹 프레임워크를 통해 등록된 경로를 감지할 수 없습니다. RouterFunction컨텍스트에서 빈을 테스트하려면 또는 를 사용하여 RouterFunction직접 가져오는 것을 고려하십시오 . @Import@SpringBootTest

@WebFluxTest@Bean유형 으로 등록된 사용자 정의 보안 구성을 감지할 수 없습니다 SecurityWebFilterChain. @Import이를 테스트에 포함하려면 또는 를 사용하여 bean을 등록하는 구성을 가져와야 합니다 @SpringBootTest.

때때로 Spring WebFlux 테스트를 작성하는 것만으로는 충분하지 않습니다. Spring Boot는 실제 서버에서 전체 종단 간 테스트를 실행할 수 있도록 도와줍니다 .

8.3.17. 자동 구성된 Spring GraphQL 테스트

Spring GraphQL은 전용 테스트 지원 모듈을 제공합니다. 프로젝트에 추가해야 합니다.

메이븐

<dependencies>
  <dependency>
    <groupId>org.springframework.graphql</groupId>
    <artifactId>spring-graphql-test</artifactId>
    <scope>test</scope>
  </dependency>
  <!-- Unless already present in the compile scope -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>

 

그레이들

dependencies {
  testImplementation("org.springframework.graphql:spring-graphql-test")
  // Unless already present in the implementation configuration
  testImplementation("org.springframework.boot:spring-boot-starter-webflux")
}

 

이 테스트 모듈은 GraphQlTester 를 제공합니다 . 테스터는 테스트에 많이 사용되므로 사용에 익숙해져야 합니다. 변형이 있으며 GraphQlTesterSpring Boot는 테스트 유형에 따라 변형을 자동 구성합니다.

• ExecutionGraphQlServiceTester클라이언트나 전송 없이 서버 측에서 테스트를 수행합니다 .
• HttpGraphQlTester라이브 서버 유무에 관계없이 서버에 연결하는 클라이언트로 테스트를 수행합니다 .

Spring Boot는 주석을 사용하여 Spring GraphQL 컨트롤러를 테스트하는 데 도움이 됩니다 @GraphQlTest. @GraphQlTest전송이나 서버가 관여하지 않고 Spring GraphQL 인프라를 자동 구성합니다. 이는 스캔된 빈을 @Controller, RuntimeWiringConfigurer, JsonComponent, Converter, GenericConverter, DataFetcherExceptionResolver및 Instrumentation로 제한합니다 GraphQlSourceBuilderCustomizer. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@GraphQlTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@GraphQlTest 수 있습니다 .

종종 @GraphQlTest컨트롤러 집합으로 제한되며 @MockBean필요한 공동 작업자에게 모의 구현을 제공하기 위해 주석과 함께 사용됩니다.

@GraphQlTest(GreetingController.class)
class GreetingControllerTests {

    @Autowired
    private GraphQlTester graphQlTester;

    @Test
    void shouldGreetWithSpecificName() {
        this.graphQlTester.document("{ greeting(name: \"Alice\") } ")
            .execute()
            .path("greeting")
            .entity(String.class)
            .isEqualTo("Hello, Alice!");
    }

    @Test
    void shouldGreetWithDefaultName() {
        this.graphQlTester.document("{ greeting } ")
            .execute()
            .path("greeting")
            .entity(String.class)
            .isEqualTo("Hello, Spring!");
    }

}

 

@SpringBootTest테스트는 전체 통합 테스트이며 전체 애플리케이션을 포함합니다. 임의 또는 정의된 포트를 사용하는 경우 라이브 서버가 구성되고 HttpGraphQlTester빈이 자동으로 제공되므로 서버를 테스트하는 데 사용할 수 있습니다. HttpGraphQlTesterMOCK 환경이 구성되면 다음과 같이 테스트 클래스에 주석을 달아 빈을 요청할 수도 있습니다 @AutoConfigureHttpGraphQlTester.

@AutoConfigureHttpGraphQlTester
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
class GraphQlIntegrationTests {

    @Test
    void shouldGreetWithSpecificName(@Autowired HttpGraphQlTester graphQlTester) {
        HttpGraphQlTester authenticatedTester = graphQlTester.mutate()
            .webTestClient((client) -> client.defaultHeaders((headers) -> headers.setBasicAuth("admin", "ilovespring")))
            .build();
        authenticatedTester.document("{ greeting(name: \"Alice\") } ")
            .execute()
            .path("greeting")
            .entity(String.class)
            .isEqualTo("Hello, Alice!");
    }

}

 

8.3.18. 자동 구성된 Data Cassandra 테스트

@DataCassandraTestCassandra 애플리케이션을 테스트하는 데 사용할 수 있습니다 . 기본적으로 를 구성하고 CassandraTemplate, 클래스를 스캔 @Table하고, Spring Data Cassandra 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot와 함께 Cassandra를 사용하는 방법에 대한 자세한 내용은 " data.html "을 참조하십시오.)@DataCassandraTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataCassandraTest 수 있습니다 .

다음 예제는 Spring Boot에서 Cassandra 테스트를 사용하기 위한 일반적인 설정을 보여줍니다.

@DataCassandraTest
class MyDataCassandraTests {

    @Autowired
    private SomeRepository repository;

}

 

8.3.19. 자동 구성된 데이터 Couchbase 테스트

Couchbase 애플리케이션을 테스트하는 데 사용할 수 있습니다 @DataCouchbaseTest. 기본적으로 CouchbaseTemplate또는 를 구성하고 ReactiveCouchbaseTemplate, 클래스를 스캔 @Document하고, Spring Data Couchbase 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Couchbase를 Spring Boot와 함께 사용하는 방법에 대한 자세한 내용은 이 장 앞부분의 " data.html "을 참조하십시오.)@DataCouchbaseTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataCouchbaseTest 수 있습니다 .

다음 예제는 Spring Boot에서 Couchbase 테스트를 사용하기 위한 일반적인 설정을 보여줍니다.

@DataCouchbaseTest
class MyDataCouchbaseTests {

    @Autowired
    private SomeRepository repository;

    // ...

}

 

8.3.20. 자동 구성된 데이터 Elasticsearch 테스트

Elasticsearch 애플리케이션을 테스트하는 데 사용할 수 있습니다 @DataElasticsearchTest. 기본적으로 를 구성하고, 클래스 ElasticsearchRestTemplate를 스캔 @Document하고, Spring Data Elasticsearch 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot에서 Elasticsearch를 사용하는 방법에 대한 자세한 내용은 이 장 앞부분의 " data.html "을 참조하십시오.)@DataElasticsearchTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataElasticsearchTest 수 있습니다 .

다음 예제는 Spring Boot에서 Elasticsearch 테스트를 사용하기 위한 일반적인 설정을 보여줍니다.

@DataElasticsearchTest
class MyDataElasticsearchTests {

    @Autowired
    private SomeRepository repository;

    // ...

}

 

8.3.21. 자동 구성된 데이터 JPA 테스트

@DataJpaTest주석을 사용하여 JPA 애플리케이션을 테스트 할 수 있습니다 . 기본적으로 클래스를 검색 @Entity하고 Spring Data JPA 리포지토리를 구성합니다. 포함된 데이터베이스가 클래스 경로에서 사용 가능한 경우 하나도 구성합니다. spring.jpa.show-sql속성을 로 설정하면 기본적으로 SQL 쿼리가 기록됩니다 true. showSql이는 주석 속성을 사용하여 비활성화할 수 있습니다 .

주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@DataJpaTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataJpaTest 수 있습니다 .

기본적으로 데이터 JPA 테스트는 트랜잭션이며 각 테스트가 끝날 때 롤백됩니다. 자세한 내용은 Spring 프레임워크 참조 문서의 관련 섹션을 참조하십시오 . 원하는 것이 아닌 경우 다음과 같이 테스트 또는 전체 클래스에 대한 트랜잭션 관리를 비활성화할 수 있습니다.

@DataJpaTest
@Transactional(propagation = Propagation.NOT_SUPPORTED)
class MyNonTransactionalTests {

    // ...

}

 

TestEntityManager데이터 JPA 테스트는 테스트용으로 특별히 설계된 표준 JPA에 대한 대안을 제공하는 빈을 주입할 수도 있습니다 EntityManager.

TestEntityManager를 추가하여 Spring 기반 테스트 클래스에 자동 구성할 수도 있습니다 @AutoConfigureTestEntityManager. @Transactional그렇게 할 때 예를 들어 테스트 클래스 또는 메서드를 추가하여 테스트가 트랜잭션에서 실행되고 있는지 확인하십시오 .

JdbcTemplate필요한 경우 A 도 사용할 수 있습니다. 다음 예는 @DataJpaTest사용 중인 주석을 보여줍니다.

@DataJpaTest
class MyRepositoryTests {

    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private UserRepository repository;

    @Test
    void testExample() {
        this.entityManager.persist(new User("sboot", "1234"));
        User user = this.repository.findByUsername("sboot");
        assertThat(user.getUsername()).isEqualTo("sboot");
        assertThat(user.getEmployeeNumber()).isEqualTo("1234");
    }

}

 

인메모리 임베디드 데이터베이스는 빠르고 설치가 필요하지 않기 때문에 일반적으로 테스트에 적합합니다. 그러나 실제 데이터베이스에 대한 테스트 실행을 선호하는 경우 @AutoConfigureTestDatabase다음 예와 같이 주석을 사용할 수 있습니다.

@DataJpaTest
@AutoConfigureTestDatabase(replace = Replace.NONE)
class MyRepositoryTests {

    // ...

}

 

8.3.22. 자동 구성된 JDBC 테스트

@JdbcTestSpring Data JDBC @DataJpaTest만 필요하고 사용하지 않는 테스트용입니다 . DataSource기본적으로 메모리 내장형 데이터베이스와 JdbcTemplate. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@JdbcTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@JdbcTest 수 있습니다 .

기본적으로 JDBC 테스트는 트랜잭션이며 각 테스트가 끝날 때 롤백됩니다. 자세한 내용은 Spring 프레임워크 참조 문서의 관련 섹션을 참조하십시오 . 원하는 것이 아닌 경우 다음과 같이 테스트 또는 전체 클래스에 대한 트랜잭션 관리를 비활성화할 수 있습니다.

@JdbcTest
@Transactional(propagation = Propagation.NOT_SUPPORTED)
class MyTransactionalTests {

}

 

@AutoConfigureTestDatabase실제 데이터베이스에 대해 테스트를 실행하려는 경우 와 동일한 방식으로 주석을 사용할 수 있습니다 DataJpaTest. (" 자동 구성된 데이터 JPA 테스트 "를 참조하십시오.)

8.3.23. 자동 구성된 데이터 JDBC 테스트

@DataJdbcTest@JdbcTestSpring Data JDBC 리포지토리를 사용하는 테스트와 유사하지만 기본적으로 인메모리 임베디드 데이터베이스, JdbcTemplate및 Spring Data JDBC 리포지토리를 구성합니다. 주석이 사용된 경우 하위 클래스 만 AbstractJdbcConfiguration스캔되고 일반 및 Bean은 스캔되지 않습니다. 콩을 포함하는 데 사용할 수 있습니다 .@DataJdbcTest@Component@ConfigurationProperties@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@DataJdbcTest 수 있습니다 .

기본적으로 데이터 JDBC 테스트는 트랜잭션이며 각 테스트가 끝날 때 롤백됩니다. 자세한 내용은 Spring 프레임워크 참조 문서의 관련 섹션을 참조하십시오 . 이것이 원하는 것이 아닌 경우 JDBC 예제에 표시된 대로 테스트 또는 전체 테스트 클래스에 대한 트랜잭션 관리를 비활성화할 수 있습니다 .

@AutoConfigureTestDatabase실제 데이터베이스에 대해 테스트를 실행하려는 경우 와 동일한 방식으로 주석을 사용할 수 있습니다 DataJpaTest. (" 자동 구성된 데이터 JPA 테스트 "를 참조하십시오.)

8.3.24. 자동 구성된 jOOQ 테스트

jOOQ 관련 테스트와 @JooqTest비슷한 방식으로 사용할 수 있습니다 . @JdbcTestjOOQ는 데이터베이스 스키마에 해당하는 Java 기반 스키마에 크게 의존하므로 기존 스키마를 DataSource사용합니다. 메모리 내 데이터베이스로 교체하려는 경우 @AutoConfigureTestDatabase해당 설정을 재정의하는 데 사용할 수 있습니다. (Spring Boot와 함께 jOOQ를 사용하는 방법에 대한 자세한 내용은 " data.html "을 참조하십시오.) 주석이 사용될 때 일반 @Component및 @ConfigurationProperties빈은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@JooqTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 목록은 부록에서 찾을@JooqTest 수 있습니다 .

@JooqTest를 구성합니다 DSLContext. 다음 예는 @JooqTest사용 중인 주석을 보여줍니다.

@JooqTest
class MyJooqTests {

    @Autowired
    private DSLContext dslContext;

    // ...

}

 

JOOQ 테스트는 트랜잭션이며 기본적으로 각 테스트가 끝날 때 롤백됩니다. 이것이 원하는 것이 아닌 경우 JDBC 예제에 표시된 대로 테스트 또는 전체 테스트 클래스에 대한 트랜잭션 관리를 비활성화할 수 있습니다 .

8.3.25. 자동 구성된 Data MongoDB 테스트

@DataMongoTestMongoDB 애플리케이션을 테스트하는 데 사용할 수 있습니다 . 기본적으로 를 구성하고 MongoTemplate, 클래스를 스캔 @Document하고, Spring Data MongoDB 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot와 함께 MongoDB를 사용하는 방법에 대한 자세한 내용은 " data.html "을 참조하십시오.)@DataMongoTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataMongoTest 수 있습니다 .

다음 클래스는 @DataMongoTest사용 중인 주석을 보여줍니다.

@DataMongoTest
class MyDataMongoDbTests {

    @Autowired
    private MongoTemplate mongoTemplate;

    // ...

}

 

8.3.26. 자동 구성된 데이터 Neo4j 테스트

Neo4j 애플리케이션을 테스트하는 데 사용할 수 있습니다 @DataNeo4jTest. 기본적으로 클래스를 검색 @Node하고 Spring Data Neo4j 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot와 함께 Neo4J를 사용하는 방법에 대한 자세한 내용은 " data.html "을 참조하십시오.)@DataNeo4jTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataNeo4jTest 수 있습니다 .

다음 예제는 Spring Boot에서 Neo4J 테스트를 사용하기 위한 일반적인 설정을 보여줍니다.

@DataNeo4jTest
class MyDataNeo4jTests {

    @Autowired
    private SomeRepository repository;

    // ...

}

 

기본적으로 Data Neo4j 테스트는 트랜잭션이며 각 테스트가 끝날 때 롤백됩니다. 자세한 내용은 Spring 프레임워크 참조 문서의 관련 섹션을 참조하십시오 . 원하는 것이 아닌 경우 다음과 같이 테스트 또는 전체 클래스에 대한 트랜잭션 관리를 비활성화할 수 있습니다.

@DataNeo4jTest
@Transactional(propagation = Propagation.NOT_SUPPORTED)
class MyDataNeo4jTests {

}

 

반응적 액세스에서는 트랜잭션 테스트가 지원되지 않습니다. 이 스타일을 사용하는 경우 @DataNeo4jTest위에서 설명한 대로 테스트를 구성해야 합니다.

8.3.27. 자동 구성된 데이터 Redis 테스트

@DataRedisTestRedis 애플리케이션을 테스트하는 데 사용할 수 있습니다 . 기본적으로 클래스를 스캔 @RedisHash하고 Spring Data Redis 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot와 함께 Redis를 사용하는 방법에 대한 자세한 내용은 " data.html "을 참조하세요.)@DataRedisTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataRedisTest 수 있습니다 .

다음 예는 @DataRedisTest사용 중인 주석을 보여줍니다.

@DataRedisTest
class MyDataRedisTests {

    @Autowired
    private SomeRepository repository;

    // ...

}

 

8.3.28. 자동 구성된 데이터 LDAP 테스트

LDAP 응용 프로그램을 테스트하는 데 사용할 수 있습니다 @DataLdapTest. 기본적으로 메모리 내 임베디드 LDAP(사용 가능한 경우)를 구성하고, 클래스 LdapTemplate를 스캔하고 @Entry, Spring Data LDAP 리포지토리를 구성합니다. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 . (Spring Boot에서 LDAP 사용에 대한 자세한 내용은 " data.html "을 참조하십시오.)@DataLdapTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@DataLdapTest 수 있습니다 .

다음 예는 @DataLdapTest사용 중인 주석을 보여줍니다.

@DataLdapTest
class MyDataLdapTests {

    @Autowired
    private LdapTemplate ldapTemplate;

    // ...

}

 

메모리 내장형 LDAP는 빠르고 개발자 설치가 필요하지 않기 때문에 일반적으로 테스트에 적합합니다. 그러나 실제 LDAP 서버에 대해 테스트를 실행하려는 경우 다음 예와 같이 내장된 LDAP 자동 구성을 제외해야 합니다.

@DataLdapTest(excludeAutoConfiguration = EmbeddedLdapAutoConfiguration.class)
class MyDataLdapTests {

    // ...

}

 

8.3.29. 자동 구성된 REST 클라이언트

@RestClientTest주석을 사용하여 REST 클라이언트를 테스트 할 수 있습니다 . RestTemplateBuilder기본적으로 Jackson, GSON 및 Jsonb 지원 을 자동 구성하고 MockRestServiceServer. 주석이 사용될 때 일반 @Component및 @ConfigurationProperties콩은 스캔되지 않습니다 . 콩을 포함하는 데 사용할 수 있습니다 .@RestClientTest@EnableConfigurationProperties@ConfigurationProperties

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@RestClientTest 수 있습니다 .

테스트하려는 특정 Bean은 다음 예제와 같이 value또는 components속성을 사용하여 지정해야 합니다.@RestClientTest

@RestClientTest(RemoteVehicleDetailsService.class)
class MyRestClientTests {

    @Autowired
    private RemoteVehicleDetailsService service;

    @Autowired
    private MockRestServiceServer server;

    @Test
    void getVehicleDetailsWhenResultIsSuccessShouldReturnDetails() {
        this.server.expect(requestTo("/greet/details")).andRespond(withSuccess("hello", MediaType.TEXT_PLAIN));
        String greeting = this.service.callRestService();
        assertThat(greeting).isEqualTo("hello");
    }

}

 

8.3.30. 자동 구성된 Spring REST 문서 테스트

주석을 사용하여 Mock MVC, REST Assured 또는 WebTestClient로 테스트에서 Spring REST Docs를@AutoConfigureRestDocs 사용할 수 있습니다 . Spring REST Docs에서 JUnit 확장이 필요하지 않습니다.

@AutoConfigureRestDocs기본 출력 디렉토리를 재정의하는 데 사용할 수 있습니다( target/generated-snippetsMaven을 사용하거나 build/generated-snippetsGradle을 사용하는 경우). 문서화된 URI에 나타나는 호스트, 체계 및 포트를 구성하는 데에도 사용할 수 있습니다.

Mock MVC로 자동 구성된 Spring REST Docs 테스트

@AutoConfigureRestDocsMockMvc서블릿 기반 웹 애플리케이션을 테스트할 때 Spring REST Docs를 사용하도록 빈을 사용자 정의합니다 . @Autowired다음 예제와 같이 Mock MVC 및 Spring REST Docs를 사용할 때 평소와 같이 사용하여 주입하고 테스트에서 사용할 수 있습니다 .

@WebMvcTest(UserController.class)
@AutoConfigureRestDocs
class MyUserDocumentationTests {

    @Autowired
    private MockMvc mvc;

    @Test
    void listUsers() throws Exception {
        this.mvc.perform(get("/users").accept(MediaType.TEXT_PLAIN))
            .andExpect(status().isOk())
            .andDo(document("list-users"));
    }

}

 

의 속성에서 제공하는 것보다 Spring REST Docs 구성에 대한 더 많은 제어가 필요한 경우 다음 예제와 같이 빈을 @AutoConfigureRestDocs사용할 수 있습니다 .RestDocsMockMvcConfigurationCustomizer

@TestConfiguration(proxyBeanMethods = false)
public class MyRestDocsConfiguration implements RestDocsMockMvcConfigurationCustomizer {

    @Override
    public void customize(MockMvcRestDocumentationConfigurer configurer) {
        configurer.snippets().withTemplateFormat(TemplateFormats.markdown());
    }

}

 

매개변수화된 출력 디렉토리에 대한 Spring REST Docs 지원을 사용하려는 경우 RestDocumentationResultHandlerbean을 작성할 수 있습니다. 자동 구성은 alwaysDo이 결과 핸들러를 사용하여 호출하므로 각 MockMvc호출이 기본 스니펫을 자동으로 생성합니다. 다음 예는 RestDocumentationResultHandler정의되는 것을 보여줍니다.

@TestConfiguration(proxyBeanMethods = false)
public class MyResultHandlerConfiguration {

    @Bean
    public RestDocumentationResultHandler restDocumentation() {
        return MockMvcRestDocumentation.document("{method-name}");
    }

}

 

WebTestClient로 자동 구성된 Spring REST Docs 테스트

@AutoConfigureRestDocs반응형 웹 애플리케이션을 테스트할 때도 함께 사용할 수 있습니다 WebTestClient. 다음 예제와 같이 Spring REST Docs를 @Autowired사용할 때 평소처럼 테스트에서 사용하고 사용하여 주입할 수 있습니다 .@WebFluxTest

@WebFluxTest
@AutoConfigureRestDocs
class MyUsersDocumentationTests {

    @Autowired
    private WebTestClient webTestClient;

    @Test
    void listUsers() {
        this.webTestClient
            .get().uri("/")
        .exchange()
        .expectStatus()
            .isOk()
        .expectBody()
            .consumeWith(document("list-users"));
    }

}

 

의 속성에서 제공하는 것보다 Spring REST Docs 구성에 대한 더 많은 제어가 필요한 경우 다음 예제와 같이 빈을 @AutoConfigureRestDocs사용할 수 있습니다 .RestDocsWebTestClientConfigurationCustomizer

@TestConfiguration(proxyBeanMethods = false)
public class MyRestDocsConfiguration implements RestDocsWebTestClientConfigurationCustomizer {

    @Override
    public void customize(WebTestClientRestDocumentationConfigurer configurer) {
        configurer.snippets().withEncoding("UTF-8");
    }

}

 

WebTestClientBuilderCustomizer매개변수화된 출력 디렉토리에 대한 Spring REST Docs 지원을 사용하려는 경우 모든 엔티티 교환 결과에 대한 소비자를 구성하는 데 사용할 수 있습니다 . 다음 예는 그러한 WebTestClientBuilderCustomizer정의를 보여줍니다.

@TestConfiguration(proxyBeanMethods = false)
public class MyWebTestClientBuilderCustomizerConfiguration {

    @Bean
    public WebTestClientBuilderCustomizer restDocumentation() {
        return (builder) -> builder.entityExchangeResultConsumer(document("{method-name}"));
    }

}

 

REST Assured로 자동 구성된 Spring REST Docs 테스트

@AutoConfigureRestDocsRequestSpecification테스트에 사용할 수 있는 Spring REST Docs를 사용하도록 미리 구성된 빈을 만듭니다 . @Autowired다음 예제와 같이 REST Assured 및 Spring REST Docs를 사용할 때 일반적으로 사용하는 것처럼 테스트에서 이를 사용하여 주입하고 사용할 수 있습니다 .

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureRestDocs
class MyUserDocumentationTests {

    @Test
    void listUsers(@Autowired RequestSpecification documentationSpec, @LocalServerPort int port) {
        given(documentationSpec)
            .filter(document("list-users"))
        .when()
            .port(port)
            .get("/")
        .then().assertThat()
            .statusCode(is(200));
    }

}

 

의 속성에서 제공하는 것보다 Spring REST Docs 구성에 대한 더 많은 제어가 필요한 경우 다음 예제와 같이 빈을 사용할 수 있습니다 @AutoConfigureRestDocs.RestDocsRestAssuredConfigurationCustomizer

@TestConfiguration(proxyBeanMethods = false)
public class MyRestDocsConfiguration implements RestDocsRestAssuredConfigurationCustomizer {

    @Override
    public void customize(RestAssuredRestDocumentationConfigurer configurer) {
        configurer.snippets().withTemplateFormat(TemplateFormats.markdown());
    }

}

 

8.3.31. 자동 구성된 Spring 웹 서비스 테스트

자동 구성된 Spring 웹 서비스 클라이언트 테스트

@WebServiceClientTestSpring Web Services 프로젝트를 사용하여 웹 서비스를 호출하는 애플리케이션을 테스트하는 데 사용할 수 있습니다 . 기본적으로 Mock WebServiceServerBean을 구성하고 자동으로 WebServiceTemplateBuilder. (Spring Boot에서 웹 서비스를 사용하는 방법에 대한 자세한 내용은 " io.html "을 참조하십시오.)

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@WebServiceClientTest 수 있습니다 .

다음 예는 @WebServiceClientTest사용 중인 주석을 보여줍니다.

@WebServiceClientTest(SomeWebService.class)
class MyWebServiceClientTests {

    @Autowired
    private MockWebServiceServer server;

    @Autowired
    private SomeWebService someWebService;

    @Test
    void mockServerCall() {
        this.server
            .expect(payload(new StringSource("<request/>")))
            .andRespond(withPayload(new StringSource("<response><status>200</status></response>")));
        assertThat(this.someWebService.test())
            .extracting(Response::getStatus)
            .isEqualTo(200);
    }

}

 

자동 구성된 Spring 웹 서비스 서버 테스트

@WebServiceServerTestSpring Web Services 프로젝트를 사용하여 웹 서비스를 구현하는 애플리케이션을 테스트하는 데 사용할 수 있습니다 . 기본적으로 MockWebServiceClient웹 서비스 끝점을 호출하는 데 사용할 수 있는 빈을 구성합니다. (Spring Boot에서 웹 서비스를 사용하는 방법에 대한 자세한 내용은 " io.html "을 참조하십시오.)

에 의해 활성화된 자동 구성 설정 목록은 부록에서 찾을@WebServiceServerTest 수 있습니다 .

다음 예는 @WebServiceServerTest사용 중인 주석을 보여줍니다.

@WebServiceServerTest(ExampleEndpoint.class)
class MyWebServiceServerTests {

    @Autowired
    private MockWebServiceClient client;

    @Test
    void mockServerCall() {
        this.client
            .sendRequest(RequestCreators.withPayload(new StringSource("<ExampleRequest/>")))
            .andExpect(ResponseMatchers.payload(new StringSource("<ExampleResponse>42</ExampleResponse>")));
    }

}

 

8.3.32. 추가 자동 구성 및 슬라이싱

@AutoConfigure…​각 슬라이스는 슬라이스의 일부로 포함되어야 하는 자동 구성을 정의하는 하나 이상의 주석을 제공합니다 . 추가 자동 구성은 사용자 지정 주석을 만들 거나 다음 예와 같이 테스트에 @AutoConfigure…​추가하여 테스트별로 추가할 수 있습니다.@ImportAutoConfiguration

@JdbcTest
@ImportAutoConfiguration(IntegrationAutoConfiguration.class)
class MyJdbcTests {

}

 

@Import자동 구성은 Spring Boot에서 특정 방식으로 처리되므로 일반 주석을 사용하여 자동 구성을 가져오지 않도록 하십시오 .

META-INF/spring또는 다음 예와 같이 저장된 파일에 슬라이스 주석을 등록하여 슬라이스 주석을 사용하기 위해 추가 자동 구성을 추가할 수 있습니다.

META-INF/spring/org.springframework.boot.test.autoconfigure.jdbc.JdbcTest.imports

com.example.IntegrationAutoConfiguration

이 예에서 는 com.example.IntegrationAutoConfiguration주석이 달린 모든 테스트에서 활성화됩니다 @JdbcTest.

#이 파일에서 주석을 사용할 수 있습니다 .

슬라이스 또는 @AutoConfigure…​주석은 메타 주석이 있는 한 이 방식으로 사용자 정의할 수 있습니다 @ImportAutoConfiguration.

8.3.33. 사용자 구성 및 슬라이싱

합리적인 방식으로 코드를 구조화 하면 기본적으로@SpringBootApplication 클래스가 테스트 구성으로 사용됩니다.

그런 다음 해당 기능의 특정 영역에 특정한 구성 설정으로 애플리케이션의 기본 클래스를 어지럽히지 않는 것이 중요해집니다.

Spring Batch를 사용 중이고 이를 위한 자동 구성에 의존한다고 가정합니다. 다음과 같이 정의할 수 있습니다 @SpringBootApplication.

@SpringBootApplication
@EnableBatchProcessing
public class MyApplication {

    // ...

}

 

이 클래스는 테스트의 소스 구성이기 때문에 모든 슬라이스 테스트는 실제로 Spring Batch를 시작하려고 시도하지만 이는 확실히 원하는 작업이 아닙니다. 권장되는 접근 방식은 다음 예제와 같이 해당 영역별 구성을 @Configuration애플리케이션과 동일한 수준의 별도 클래스로 이동하는 것입니다.

@Configuration(proxyBeanMethods = false)
@EnableBatchProcessing
public class MyBatchConfiguration {

    // ...

}

 

애플리케이션의 복잡성에 따라 @Configuration사용자 지정을 위한 단일 클래스 또는 도메인 영역당 하나의 클래스가 있을 수 있습니다. 후자의 접근 방식을 사용하면 필요한 경우 주석을 사용하여 테스트 중 하나에서 활성화할 수 있습니다 @Import. 조각 테스트를 위해 특정 클래스를 활성화하려는 경우에 대한 자세한 내용은 이 방법 섹션을 참조하세요 @Configuration.

테스트 조각은 @Configuration스캔에서 클래스를 제외합니다. 예를 들어 a의 경우 @WebMvcTest다음 구성은 WebMvcConfigurer테스트 조각에 의해 로드된 애플리케이션 컨텍스트에 지정된 빈을 포함하지 않습니다.

@Configuration(proxyBeanMethods = false)
public class MyWebConfiguration {

    @Bean
    public WebMvcConfigurer testConfigurer() {
        return new WebMvcConfigurer() {
            // ...
        };
    }

}

 

그러나 아래 구성은 사용자 정의가 WebMvcConfigurer테스트 조각에 의해 로드되게 합니다.

@Component
public class MyWebMvcConfigurer implements WebMvcConfigurer {

    // ...

}

 

혼동의 또 다른 원인은 클래스 경로 스캐닝입니다. 합리적인 방식으로 코드를 구성하는 동안 추가 패키지를 스캔해야 한다고 가정합니다. 애플리케이션은 다음 코드와 유사할 수 있습니다.

@SpringBootApplication
@ComponentScan({ "com.example.app", "com.example.another" })
public class MyApplication {

    // ...

}

 

이렇게 하면 선택한 조각에 관계없이 두 패키지를 스캔하는 부작용으로 기본 구성 요소 스캔 지시문을 효과적으로 재정의합니다. 예를 들어 a는 @DataJpaTest갑자기 응용 프로그램의 구성 요소와 사용자 구성을 스캔하는 것 같습니다. 다시 말하지만 사용자 지정 지시문을 별도의 클래스로 이동하는 것은 이 문제를 해결하는 좋은 방법입니다.

이것이 옵션이 아닌 경우 @SpringBootConfiguration대신 사용되도록 테스트 계층 구조의 어딘가에 만들 수 있습니다. 또는 테스트 소스를 지정하여 기본 소스를 찾는 동작을 비활성화할 수 있습니다.

8.3.34. Spock을 사용하여 Spring Boot 애플리케이션 테스트

Spock 2.2 이상을 사용하여 Spring Boot 애플리케이션을 테스트할 수 있습니다. 이렇게 하려면 응용 프로그램 빌드에 -groovy-4.0Spock 모듈 버전 에 대한 종속성을 추가합니다. Spring의 테스트 프레임워크를 Spock에 통합합니다. 자세한 내용은 Spock의 Spring 모듈 문서를 참조하십시오 .spock-springspock-spring

8.4. 테스트 유틸리티

애플리케이션을 테스트할 때 일반적으로 유용한 몇 가지 테스트 유틸리티 클래스가 의 일부로 패키지되어 있습니다 spring-boot.

8.4.1. ConfigDataApplicationContextInitializer

ConfigDataApplicationContextInitializerApplicationContextInitializer테스트에 적용하여 Spring Boot 파일을 로드할 수 있습니다 application.properties. @SpringBootTest다음 예와 같이 에서 제공하는 전체 기능 세트가 필요하지 않은 경우 사용할 수 있습니다 .

@ContextConfiguration(classes = Config.class, initializers = ConfigDataApplicationContextInitializer.class)
class MyConfigFileTests {

    // ...

}

 

단독 사용은 주입을 ConfigDataApplicationContextInitializer지원하지 않습니다 @Value("${…​}"). 유일한 작업은 application.properties파일이 Spring의 Environment. 지원을 받으려면 @Valuea를 추가로 구성하거나 자동으로 구성하는 를 PropertySourcesPlaceholderConfigurer사용해야 합니다 .@SpringBootTest

8.4.2. TestPropertyValues

TestPropertyValuesConfigurableEnvironment또는 에 속성을 빠르게 추가할 수 있습니다 ConfigurableApplicationContext. key=value다음과 같이 문자열 로 호출할 수 있습니다 .

class MyEnvironmentTests {

    @Test
    void testPropertySources() {
        MockEnvironment environment = new MockEnvironment();
        TestPropertyValues.of("org=Spring", "name=Boot").applyTo(environment);
        assertThat(environment.getProperty("name")).isEqualTo("Boot");
    }

}

 

8.4.3. 출력캡처

OutputCapture캡처 및 출력 Extension에 사용할 수 있는 JUnit입니다 . 이를 사용하려면 다음과 같이 테스트 클래스 생성자 또는 테스트 메서드에 인수를 추가 하고 주입합니다 .System.outSystem.err@ExtendWith(OutputCaptureExtension.class)CapturedOutput

@ExtendWith(OutputCaptureExtension.class)
class MyOutputCaptureTests {

    @Test
    void testName(CapturedOutput output) {
        System.out.println("Hello World!");
        assertThat(output).contains("World");
    }

}

 

8.4.4. TestRestTemplate

TestRestTemplate is a convenience alternative to Spring’s RestTemplate that is useful in integration tests. You can get a vanilla template or one that sends Basic HTTP authentication (with a username and password). In either case, the template is fault tolerant. This means that it behaves in a test-friendly way by not throwing exceptions on 4xx and 5xx errors. Instead, such errors can be detected through the returned ResponseEntity and its status code.

Spring Framework 5.0 provides a new WebTestClient that works for WebFlux integration tests and both WebFlux and MVC end-to-end testing. It provides a fluent API for assertions, unlike TestRestTemplate.

Apache HTTP 클라이언트(버전 5.1 이상)를 사용하는 것이 권장되지만 필수는 아닙니다. 클래스 경로에 있는 경우 TestRestTemplate클라이언트를 적절하게 구성하여 응답합니다. Apache의 HTTP 클라이언트를 사용하는 경우 몇 가지 추가 테스트 친화적 기능이 활성화됩니다.

• 리디렉션은 따르지 않습니다(따라서 응답 위치를 어설션할 수 있음).
• 쿠키는 무시됩니다(따라서 템플릿은 상태 비저장임).

TestRestTemplate다음 예제와 같이 통합 테스트에서 직접 인스턴스화할 수 있습니다.

class MyTests {

    private final TestRestTemplate template = new TestRestTemplate();

    @Test
    void testRequest() {
        ResponseEntity<String> headers = this.template.getForEntity("https://myhost.example.com/example", String.class);
        assertThat(headers.getHeaders().getLocation()).hasHost("other.example.com");
    }

}

 

또는 또는 @SpringBootTest와 함께 주석을 사용하는 경우 완전히 구성된 것을 주입 하고 사용을 시작할 수 있습니다. 필요한 경우 Bean을 통해 추가 사용자 정의를 적용할 수 있습니다. 호스트와 포트를 지정하지 않는 모든 URL은 다음 예와 같이 내장 서버에 자동으로 연결됩니다.WebEnvironment.RANDOM_PORTWebEnvironment.DEFINED_PORTTestRestTemplateRestTemplateBuilder

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class MySpringBootTests {

    @Autowired
    private TestRestTemplate template;

    @Test
    void testRequest() {
        HttpHeaders headers = this.template.getForEntity("/example", String.class).getHeaders();
        assertThat(headers.getLocation()).hasHost("other.example.com");
    }

    @TestConfiguration(proxyBeanMethods = false)
    static class RestTemplateBuilderConfiguration {

        @Bean
        RestTemplateBuilder restTemplateBuilder() {
            return new RestTemplateBuilder().setConnectTimeout(Duration.ofSeconds(1))
                .setReadTimeout(Duration.ofSeconds(1));
        }

    }

}

 

9. 나만의 자동 구성 만들기

공유 라이브러리를 개발하는 회사에서 일하거나 오픈 소스 또는 상용 라이브러리에서 작업하는 경우 고유한 자동 구성을 개발할 수 있습니다. 자동 구성 클래스는 외부 jar에 번들로 제공될 수 있으며 여전히 Spring Boot에서 선택할 수 있습니다.

자동 구성은 자동 구성 코드와 함께 사용할 일반적인 라이브러리를 제공하는 "스타터"에 연결할 수 있습니다. 먼저 자체 자동 구성을 구축하기 위해 알아야 할 사항을 다룬 다음 사용자 정의 스타터를 만드는 데 필요한 일반적인 단계 로 이동합니다 .

 

9.1. 자동 구성된 Bean 이해

자동 구성을 구현하는 클래스에는 @AutoConfiguration. @Configuration이 주석 자체는 자동 구성을 표준 클래스 로 만드는 메타 주석입니다 @Configuration. @Conditional자동 구성을 적용해야 하는 경우를 제한하기 위해 추가 주석이 사용됩니다. 일반적으로 자동 구성 클래스는 @ConditionalOnClass및 @ConditionalOnMissingBean주석을 사용합니다. 이렇게 하면 관련 클래스가 발견되고 자신의 를 선언하지 않은 경우에만 자동 구성이 적용됩니다 @Configuration.

spring-boot-autoconfigureSpring이 제공하는 클래스를 보려면 소스 코드를 탐색할 수 있습니다 @AutoConfiguration( META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports파일 참조).

9.2. 자동 구성 후보 찾기

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsSpring Boot는 게시된 jar 내에 파일이 있는지 확인합니다 . 파일은 다음 예제와 같이 한 줄에 하나의 클래스 이름으로 구성 클래스를 나열해야 합니다.

com.mycorp.libx.autoconfigure.LibXAutoConfiguration
com.mycorp.libx.autoconfigure.LibXWebAutoConfiguration

문자를 사용하여 가져오기 파일에 주석을 추가할 수 있습니다 #.

자동 구성은 가져오기 파일에 이름을 지정하여 로드 해야 합니다. 특정 패키지 공간에 정의되어 있고 구성 요소 검색 대상이 아닌지 확인하십시오. 또한 자동 구성 클래스는 추가 구성 요소를 찾기 위해 구성 요소 검색을 활성화해서는 안 됩니다. 대신 특정 @Import주석을 사용해야 합니다.

구성을 특정 순서로 적용해야 하는 경우 주석 또는 전용 및 주석 에서 , 및 속성을 before사용할 수 있습니다 . 예를 들어 웹별 구성을 제공하는 경우 클래스는 .beforeNameafterafterName@AutoConfiguration@AutoConfigureBefore@AutoConfigureAfterWebMvcAutoConfiguration

서로에 대한 직접적인 지식이 없어야 하는 특정 자동 구성을 주문하려는 경우 를 사용할 수도 있습니다 @AutoConfigureOrder. 해당 주석은 일반 @Order주석과 동일한 의미 체계를 갖지만 자동 구성 클래스에 대한 전용 순서를 제공합니다.

표준 클래스와 마찬가지로 @Configuration자동 구성 클래스가 적용되는 순서는 Bean이 정의되는 순서에만 영향을 미칩니다. 해당 빈이 이후에 생성되는 순서는 영향을 받지 않으며 각 빈의 종속성 및 @DependsOn관계에 의해 결정됩니다.

9.3. 조건 주석

@Conditional거의 항상 자동 구성 클래스에 하나 이상의 주석을 포함하려고 합니다 . 주석은 @ConditionalOnMissingBean개발자가 기본값에 만족하지 않는 경우 자동 구성을 재정의할 수 있도록 하는 데 사용되는 일반적인 예입니다.

Spring Boot에는 클래스 또는 개별 메서드 @Conditional에 주석을 달아 자신의 코드에서 재사용할 수 있는 여러 주석이 포함되어 있습니다 . 이러한 주석에는 다음이 포함됩니다.@Configuration@Bean

• 클래스 조건
• 빈 상태
• 부동산 조건
• 자원 조건
• 웹 애플리케이션 조건
• SpEL 발현 조건

9.3.1. 클래스 조건

@ConditionalOnClass및 주석 @ConditionalOnMissingClass을 사용하면 @Configuration특정 클래스의 존재 여부에 따라 클래스를 포함할 수 있습니다. 어노테이션 메타데이터가 ASM을 사용하여 구문 분석된다는 사실로 인해 value해당 클래스가 실행 중인 애플리케이션 클래스 경로에 실제로 나타나지 않더라도 속성을 사용하여 실제 클래스를 참조할 수 있습니다 . name값 을 사용하여 클래스 이름을 지정하려는 경우 특성을 사용할 수도 있습니다 String.

이 메커니즘은 일반적으로 반환 유형이 조건의 대상인 메서드에 동일한 방식으로 적용되지 않습니다 @Bean. 메서드에 대한 조건이 적용되기 전에 JVM은 클래스를 로드하고 잠재적으로 처리된 메서드 참조를 클래스가 아닌 경우 실패합니다. 현재의.

이 시나리오를 처리하기 위해 @Configuration다음 예제와 같이 별도의 클래스를 사용하여 조건을 격리할 수 있습니다.

@AutoConfiguration
// Some conditions ...
public class MyAutoConfiguration {

    // Auto-configured beans ...

    @Configuration(proxyBeanMethods = false)
    @ConditionalOnClass(SomeService.class)
    public static class SomeServiceConfiguration {

        @Bean
        @ConditionalOnMissingBean
        public SomeService someService() {
            return new SomeService();
        }

    }

}

 

@ConditionalOnClass자신이 작성한 주석을 작성하기 위해 메타 주석의 일부로 또는를 사용하는 경우 클래스를 참조하여 @ConditionalOnMissingClass사용해야 하며, 이 경우 처리되지 않습니다.name

9.3.2. 빈 상태

@ConditionalOnBean및 주석 @ConditionalOnMissingBean을 사용하면 특정 빈의 유무에 따라 빈을 포함할 수 있습니다. 속성 을 사용하여 value유형별로 빈을 지정하거나 name이름별로 빈을 지정할 수 있습니다. 속성 을 사용하면 Bean을 검색할 때 고려해야 하는 계층 구조를 search제한할 수 있습니다 .ApplicationContext

메서드 에 배치되면 @Bean대상 유형은 다음 예제와 같이 기본적으로 메서드의 반환 유형이 됩니다.

@AutoConfiguration
public class MyAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public SomeService someService() {
        return new SomeService();
    }

}

 

앞의 예제에서 someService빈 유형이 SomeService이미 ApplicationContext.

이러한 조건은 지금까지 처리된 내용을 기반으로 평가되므로 Bean 정의가 추가되는 순서에 매우 주의해야 합니다. @ConditionalOnBean이러한 이유로 자동 구성 클래스에 대한 주석 만 사용하는 것이 좋습니다 @ConditionalOnMissingBean(사용자 정의 빈 정의가 추가된 후 로드가 보장되기 때문입니다).

@ConditionalOnBean클래스 생성을 @ConditionalOnMissingBean막지 마십시오 . @Configuration클래스 수준에서 이러한 조건을 사용하는 것과 각 포함된 @Bean메서드를 주석으로 표시하는 것의 유일한 차이점은 전자는 @Configuration조건이 일치하지 않는 경우 클래스가 빈으로 등록되는 것을 방지한다는 것입니다.

메소드 를 선언할 때 @Bean메소드의 리턴 유형에 가능한 한 많은 유형 정보를 제공하십시오. 예를 들어 빈의 구체적인 클래스가 인터페이스를 구현하는 경우 빈 메서드의 반환 유형은 인터페이스가 아닌 구체적인 클래스여야 합니다. 메소드 에서 가능한 한 많은 유형 정보를 제공하는 것은 @Bean평가가 메소드 서명에서 사용 가능한 유형 정보에만 의존할 수 있으므로 Bean 조건을 사용할 때 특히 중요합니다.

9.3.3. 부동산 조건

주석 @ConditionalOnProperty을 사용하면 Spring 환경 속성을 기반으로 구성을 포함할 수 있습니다. prefix및 특성을 사용하여 name확인해야 하는 속성을 지정합니다. 기본적으로 존재하지만 같지 않은 모든 속성이 false일치합니다. havingValue및 속성을 사용하여 고급 검사를 생성할 수도 있습니다 matchIfMissing.

9.3.4. 자원 조건

주석 @ConditionalOnResource을 사용하면 특정 리소스가 있는 경우에만 구성을 포함할 수 있습니다. 리소스는 다음 예제와 같이 일반적인 Spring 규칙을 사용하여 지정할 수 있습니다 file:/home/user/test.dat.

9.3.5. 웹 애플리케이션 조건

@ConditionalOnWebApplication및 주석 @ConditionalOnNotWebApplication을 사용하면 애플리케이션이 웹 애플리케이션인지 여부에 따라 구성이 포함됩니다. 서블릿 기반 웹 애플리케이션은 Spring을 사용하거나 범위 WebApplicationContext를 정의 session하거나 ConfigurableWebEnvironment. 반응형 웹 애플리케이션은 를 사용하거나 ReactiveWebApplicationContext가 있는 모든 애플리케이션입니다 ConfigurableReactiveWebEnvironment.

및 주석을 사용하면 애플리케이션이 서블릿 컨테이너에 배포되는 기존 @ConditionalOnWarDeploymentWAR @ConditionalOnNotWarDeployment애플리케이션인지 여부에 따라 구성을 포함할 수 있습니다. 이 조건은 내장 웹 서버로 실행되는 응용 프로그램과 일치하지 않습니다.

9.3.6. SpEL 발현 조건

주석 을 사용하면 SpEL 표현식@ConditionalOnExpression 의 결과에 따라 구성을 포함할 수 있습니다 .

식에서 빈을 참조하면 해당 빈이 컨텍스트 새로 고침 처리 초기에 초기화됩니다. 결과적으로 bean은 사후 처리(예: 구성 속성 바인딩)에 적합하지 않으며 해당 상태가 불완전할 수 있습니다.

9.4. 자동 구성 테스트

자동 구성은 사용자 구성( @Bean정의 및 Environment사용자 지정), 조건 평가(특정 라이브러리의 존재) 등 여러 요인의 영향을 받을 수 있습니다. 구체적으로 각 테스트는 ApplicationContext이러한 사용자 지정의 조합을 나타내는 잘 정의된 테스트를 생성해야 합니다. ApplicationContextRunner이를 달성할 수 있는 좋은 방법을 제공합니다.

ApplicationContextRunner일반적으로 기본 공통 구성을 수집하기 위한 테스트 클래스의 필드로 정의됩니다. 다음 예제에서는 MyServiceAutoConfiguration항상 호출되는지 확인합니다.

private final ApplicationContextRunner contextRunner = new ApplicationContextRunner()
    .withConfiguration(AutoConfigurations.of(MyServiceAutoConfiguration.class));

 

여러 자동 구성을 정의해야 하는 경우 애플리케이션을 실행할 때와 정확히 동일한 순서로 호출되므로 선언 순서를 지정할 필요가 없습니다.

각 테스트는 러너를 사용하여 특정 사용 사례를 나타낼 수 있습니다. 예를 들어 아래 샘플은 사용자 구성( UserConfiguration)을 호출하고 자동 구성이 제대로 백오프되는지 확인합니다. 호출은 run와 함께 사용할 수 있는 콜백 컨텍스트를 제공합니다 AssertJ.

@Test
void defaultServiceBacksOff() {
    this.contextRunner.withUserConfiguration(UserConfiguration.class).run((context) -> {
        assertThat(context).hasSingleBean(MyService.class);
        assertThat(context).getBean("myCustomService").isSameAs(context.getBean(MyService.class));
    });
}

@Configuration(proxyBeanMethods = false)
static class UserConfiguration {

    @Bean
    MyService myCustomService() {
        return new MyService("mine");
    }

}

 

Environment다음 예와 같이 를 쉽게 사용자 정의할 수도 있습니다 .

@Test
void serviceNameCanBeConfigured() {
    this.contextRunner.withPropertyValues("user.name=test123").run((context) -> {
        assertThat(context).hasSingleBean(MyService.class);
        assertThat(context.getBean(MyService.class).getName()).isEqualTo("test123");
    });
}

 

러너를 사용하여 를 표시할 수도 있습니다 ConditionEvaluationReport. 보고서는 INFO또는 DEBUG레벨에서 인쇄할 수 있습니다. 다음 예는 를 사용하여 ConditionEvaluationReportLoggingListener자동 구성 테스트에서 보고서를 인쇄하는 방법을 보여줍니다.

class MyConditionEvaluationReportingTests {

    @Test
    void autoConfigTest() {
        new ApplicationContextRunner()
            .withInitializer(ConditionEvaluationReportLoggingListener.forLogLevel(LogLevel.INFO))
            .run((context) -> {
                    // Test something...
            });
    }

}

 

9.4.1. 웹 컨텍스트 시뮬레이션

서블릿 또는 반응형 웹 애플리케이션 컨텍스트에서만 작동하는 자동 구성을 테스트해야 하는 경우 각각 WebApplicationContextRunner또는를 사용하십시오 ReactiveWebApplicationContextRunner.

9.4.2. 클래스 경로 재정의

런타임에 특정 클래스 및/또는 패키지가 없을 때 발생하는 상황을 테스트하는 것도 가능합니다. Spring Boot는 FilteredClassLoader러너가 쉽게 사용할 수 있는 와 함께 제공됩니다. 다음 예에서는 가 MyService없으면 자동 구성이 적절하게 비활성화된 것입니다.

@Test
void serviceIsIgnoredIfLibraryIsNotPresent() {
    this.contextRunner.withClassLoader(new FilteredClassLoader(MyService.class))
        .run((context) -> assertThat(context).doesNotHaveBean("myService"));
}

 

9.5. 나만의 스타터 만들기

일반적인 Spring Boot 스타터에는 주어진 기술의 인프라를 자동 구성하고 사용자 정의하는 코드가 포함되어 있습니다. 이를 "acme"라고 부르겠습니다. 쉽게 확장할 수 있도록 전용 네임스페이스의 여러 구성 키를 환경에 노출할 수 있습니다. 마지막으로 사용자가 가능한 한 쉽게 시작할 수 있도록 단일 "시작" 종속성이 제공됩니다.

구체적으로 사용자 지정 스타터에는 다음이 포함될 수 있습니다.

• autoconfigure"acme"에 대한 자동 구성 코드를 포함하는 모듈입니다 .
• "acme" 및 일반적으로 유용한 추가 종속성뿐만 아니라 모듈 starter에 대한 종속성을 제공하는 모듈입니다 . autoconfigure간단히 말해서 스타터를 추가하면 해당 라이브러리 사용을 시작하는 데 필요한 모든 것이 제공됩니다.

두 모듈의 이러한 분리는 전혀 필요하지 않습니다. "acme"에 여러 가지 특징, 옵션 또는 선택적 기능이 있는 경우 일부 기능이 선택적이라는 사실을 명확하게 표현할 수 있으므로 자동 구성을 분리하는 것이 좋습니다. 게다가 이러한 선택적 종속성에 대한 의견을 제공하는 스타터를 만들 수 있습니다. 동시에 다른 사람들은 autoconfigure모듈에만 의존하고 다른 의견으로 자신의 스타터를 만들 수 있습니다.

자동 구성이 비교적 간단하고 옵션 기능이 없는 경우 스타터에서 두 모듈을 병합하는 것이 확실히 옵션입니다.

9.5.1. 명명

스타터에 적절한 네임스페이스를 제공해야 합니다. spring-boot다른 Maven을 사용하더라도 모듈 이름을 로 시작하지 마십시오 groupId. 향후 자동 구성 항목에 대한 공식 지원을 제공할 수 있습니다.

일반적으로 스타터 뒤에 결합된 모듈의 이름을 지정해야 합니다. 예를 들어, "acme"에 대한 스타터를 만들고 자동 구성 모듈 acme-spring-boot및 스타터 의 이름을 지정한다고 가정합니다 acme-spring-boot-starter. 두 개를 결합하는 모듈이 하나만 있는 경우 이름을 로 지정합니다 acme-spring-boot-starter.

9.5.2. 구성 키

스타터가 구성 키를 제공하는 경우 고유한 네임스페이스를 사용하십시오. 특히 Spring Boot가 사용하는 네임스페이스(예 server: management, spring, 등)에 키를 포함하지 마십시오. 동일한 네임스페이스를 사용하는 경우 향후 모듈을 손상시키는 방식으로 이러한 네임스페이스를 수정할 수 있습니다. 일반적으로 소유한 네임스페이스를 모든 키에 접두사로 지정합니다(예: acme).

다음 예제와 같이 각 속성에 대한 필드 javadoc를 추가하여 구성 키가 문서화되었는지 확인하십시오.

@ConfigurationProperties("acme")
public class AcmeProperties {

    /**
     * Whether to check the location of acme resources.
     */
    private boolean checkLocation = true;

    /**
     * Timeout for establishing a connection to the acme server.
     */
    private Duration loginTimeout = Duration.ofSeconds(3);

    // getters/setters ...

}

 

@ConfigurationPropertiesJSON에 추가되기 전에는 처리되지 않으므로 Javadoc 필드 에는 일반 텍스트만 사용해야 합니다 .

다음은 설명의 일관성을 유지하기 위해 내부적으로 준수하는 몇 가지 규칙입니다.

• 설명을 "The" 또는 "A"로 시작하지 마십시오.
• 유형 의 경우 boolean"여부" 또는 "활성화"로 설명을 시작합니다.
• 컬렉션 기반 유형의 경우 "쉼표로 구분된 목록"으로 설명을 시작합니다.
• "기간 접미사를 지정하지 않으면 초가 사용됩니다"와 같이 기본 단위가 밀리초와 다른 경우 java.time.Duration대신 사용하고 설명 합니다 .long
• 런타임에 결정해야 하는 경우가 아니면 설명에 기본값을 제공하지 마십시오.

키에 대해서도 IDE 지원을 사용할 수 있도록 메타 데이터 생성을 트리거 해야 합니다 . META-INF/spring-configuration-metadata.json키가 제대로 문서화되었는지 확인하기 위해 생성된 메타데이터( )를 검토할 수 있습니다 . 호환되는 IDE에서 자신의 스타터를 사용하는 것도 메타데이터의 품질을 검증하는 좋은 생각입니다.

9.5.3. "자동 구성" 모듈

모듈 autoconfigure에는 라이브러리를 시작하는 데 필요한 모든 것이 포함되어 있습니다. 또한 구성 키 정의(예: @ConfigurationProperties) 및 구성 요소 초기화 방법을 추가로 사용자 지정하는 데 사용할 수 있는 콜백 인터페이스를 포함할 수 있습니다.

autoconfigure프로젝트에 모듈을 더 쉽게 포함할 수 있도록 라이브러리에 대한 종속성을 선택 사항으로 표시해야 합니다 . 그렇게 하면 라이브러리가 제공되지 않고 기본적으로 스프링부트가 백오프된다.

Spring Boot는 주석 프로세서를 사용하여 메타데이터 파일( )에서 자동 구성에 대한 조건을 수집합니다 META-INF/spring-autoconfigure-metadata.properties. 해당 파일이 있으면 일치하지 않는 자동 구성을 적극적으로 필터링하여 시작 시간을 개선하는 데 사용됩니다.

Maven으로 빌드할 때 자동 구성이 포함된 모듈에 다음 종속성을 추가하는 것이 좋습니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-autoconfigure-processor</artifactId>
    <optional>true</optional>
</dependency>

 

애플리케이션에서 직접 자동 구성을 정의한 경우 목표가 fat jar에 종속성을 추가 spring-boot-maven-plugin하지 않도록 구성해야 합니다.repackage

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.springframework.boot</groupId>
                            <artifactId>spring-boot-autoconfigure-processor</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

 

annotationProcessorGradle을 사용하면 다음 예제와 같이 구성 에서 종속성을 선언해야 합니다 .

dependencies {
    annotationProcessor "org.springframework.boot:spring-boot-autoconfigure-processor"
}

 

9.5.4. 스타터 모듈

스타터는 정말 빈 병입니다. 유일한 목적은 라이브러리 작업에 필요한 종속성을 제공하는 것입니다. 시작하는 데 필요한 것이 무엇인지에 대한 독단적인 견해라고 생각할 수 있습니다.

스타터가 추가된 프로젝트에 대해 가정하지 마십시오. 자동 구성 중인 라이브러리에 일반적으로 다른 스타터가 필요한 경우 해당 항목도 언급하십시오. 라이브러리의 일반적인 사용에 불필요한 종속성을 포함하지 않아야 하므로 선택적 종속성의 수가 많은 경우 적절한 기본 종속성 세트를 제공하는 것이 어려울 수 있습니다. 즉, 선택적 종속성을 포함해서는 안 됩니다.

어느 쪽이든 스타터는 핵심 Spring Boot 스타터( spring-boot-starter)를 직접 또는 간접적으로 참조해야 합니다(스타터가 다른 스타터에 의존하는 경우 추가할 필요가 없음). 사용자 정의 스타터만으로 프로젝트를 생성한 경우 Spring Boot의 핵심 기능은 코어 스타터의 존재에 의해 존중됩니다.

10. 코틀린 지원

Kotlin 은 JVM(및 기타 플랫폼)을 대상으로 하는 정적으로 유형이 지정된 언어로, Java로 작성된 기존 라이브러리와의 상호 운용성을 제공하면서 간결하고 우아한 코드를 작성할 수 있습니다.

Spring Boot는 Spring Framework, Spring Data 및 Reactor와 같은 다른 Spring 프로젝트의 지원을 활용하여 Kotlin 지원을 제공합니다. 자세한 내용은 Spring Framework Kotlin 지원 문서를 참조하세요 .

Spring Boot와 Kotlin을 시작하는 가장 쉬운 방법은 이 포괄적인 자습서를 따르는 것입니다 . start.spring.io 를 사용하여 새로운 Kotlin 프로젝트를 생성할 수 있습니다 . Kotlin Slack 의 #spring 채널에 자유롭게 참여하거나 지원이 필요한 경우 Stack Overflow 의 spring및 태그를 사용하여 질문하세요 .kotlin

10.1. 요구 사항

Spring Boot는 Kotlin 1.7.x 이상이 필요하며 종속성 관리를 통해 적합한 Kotlin 버전을 관리합니다. Kotlin을 사용하려면 클래스 경로에 있어야 합니다 org.jetbrains.kotlin:kotlin-stdlib. org.jetbrains.kotlin:kotlin-reflect변형 및 사용할 수도 있습니다 kotlin-stdlib.kotlin-stdlib-jdk7kotlin-stdlib-jdk8

Kotlin 클래스는 기본적으로 최종 클래스 이므로 프록시될 수 있도록 Spring 주석 클래스를 자동으로 열도록 kotlin-spring 플러그인을 구성할 수 있습니다 .

JSON 데이터를 Kotlin에서 직렬화/역직렬화하려면 Jackson의 Kotlin 모듈이 필요합니다. 클래스 경로에서 찾으면 자동으로 등록됩니다. Jackson과 Kotlin이 있지만 Jackson Kotlin 모듈이 없으면 경고 메시지가 기록됩니다.

이러한 종속성과 플러그인은 start.spring.io 에서 Kotlin 프로젝트를 부트스트랩하는 경우 기본적으로 제공됩니다 .

10.2. Null 안전

Kotlin의 주요 기능 중 하나는 null-safety 입니다 . null문제를 런타임으로 미루고 NullPointerException. 이것은 Optional. Kotlin은 또한 Kotlin의 null-safety에 대한 포괄적인 가이드 에 설명된 대로 nullable 값이 있는 기능적 구조를 사용할 수 있습니다 .

Java는 유형 시스템에서 null 안전을 표현하는 것을 허용하지 않지만 Spring Framework, Spring Data 및 Reactor는 이제 도구 친화적인 주석을 통해 API의 null 안전을 제공합니다. 기본적으로 Kotlin에서 사용되는 Java API의 유형은 null 검사가 완화된 플랫폼 유형 으로 인식됩니다 . null 허용 여부 주석과 결합된 JSR 305 주석에 대한 Kotlin의 지원은 Kotlin의 관련 Spring API에 대한 null 안전성을 제공합니다.

-Xjsr305다음 옵션과 함께 컴파일러 플래그를 추가하여 JSR 305 검사를 구성할 수 있습니다 -Xjsr305={strict|warn|ignore}. 기본 동작은 와 동일합니다 -Xjsr305=warn. 이 strict값은 Spring API에서 유추된 Kotlin 유형에서 null 안전성을 고려하는 데 필요하지만 Spring API null 허용 여부 선언은 마이너 릴리스 간에도 발전할 수 있으며 향후 더 많은 검사가 추가될 수 있다는 점을 알고 사용해야 합니다.

일반 형식 인수, varargs 및 배열 요소 null 허용 여부는 아직 지원되지 않습니다. 최신 정보는 SPR-15942를 참조하십시오 . 또한 Spring Boot의 자체 API에는 아직 주석이 달려 있지 않습니다 .

10.3. 코틀린 API

10.3.1. 실행 응용 프로그램

runApplication<MyApplication>(*args)Spring Boot는 다음 예제와 같이 애플리케이션을 실행하는 관용적인 방법을 제공합니다 .

@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
    runApplication<MyApplication>(*args)
}

 

이것은 SpringApplication.run(MyApplication::class.java, *args). 또한 다음 예와 같이 애플리케이션을 사용자 정의할 수 있습니다.

runApplication<MyApplication>(*args) {
    setBannerMode(OFF)
}

 

10.3.2. 확장 프로그램

Kotlin 확장 기능은 추가 기능으로 기존 클래스를 확장하는 기능을 제공합니다. Spring Boot Kotlin API는 이러한 확장을 사용하여 기존 API에 새로운 Kotlin 관련 편의를 추가합니다.

TestRestTemplateSpring Framework에서 Spring Framework에서 제공하는 것과 유사한 확장 기능을 RestOperations제공합니다. 무엇보다도 확장 기능을 통해 Kotlin 구체화 유형 매개변수를 활용할 수 있습니다.

10.4. 종속성 관리

클래스 경로에서 서로 다른 버전의 Kotlin 종속성이 혼합되는 것을 방지하기 위해 Spring Boot는 Kotlin BOM을 가져옵니다.

Maven에서는 kotlin.version속성을 설정하여 Kotlin 버전을 사용자 정의할 수 있으며 kotlin-maven-plugin. Gradle을 사용하면 Spring Boot 플러그인이 자동으로 kotlin.versionKotlin 플러그인 버전에 맞춰집니다.

또한 Spring Boot는 Kotlin 코루틴 BOM을 가져와서 코루틴 종속성 버전을 관리합니다. 속성 을 설정하여 버전을 사용자 정의할 수 있습니다 kotlin-coroutines.version.

org.jetbrains.kotlinx:kotlinx-coroutines-reactorstart.spring.io 에 대한 반응형 종속성이 하나 이상 있는 Kotlin 프로젝트를 부트스트랩하는 경우 기본적으로 종속성이 제공됩니다 .

10.5. @ConfigurationProperties

@ConfigurationProperties생성자 바인딩 과 함께 사용하면 val다음 예제와 같이 변경할 수 없는 속성이 있는 클래스를 지원합니다 .

@ConfigurationProperties("example.kotlin")
data class KotlinExampleProperties(
        val name: String,
        val description: String,
        val myService: MyService) {

    data class MyService(
            val apiToken: String,
            val uri: URI
    )
}

 

주석 프로세서를 사용하여 고유한 메타데이터를 생성하려면 종속성을 사용하여 kapt구성해야 합니다spring-boot-configuration-processor . 일부 기능(예: 기본값 또는 사용되지 않는 항목 검색)은 kapt가 제공하는 모델의 제한으로 인해 작동하지 않습니다.

10.6. 테스트

JUnit 4를 사용하여 Kotlin 코드를 테스트할 수 있지만 JUnit 5가 기본적으로 제공되며 권장됩니다. JUnit 5를 사용하면 테스트 클래스를 한 번 인스턴스화하고 모든 클래스 테스트에 재사용할 수 있습니다. @BeforeAll이렇게 하면 비정적 메서드에서 주석 을 사용할 수 있으며 @AfterAllKotlin에 적합합니다.

Kotlin 클래스를 모의하려면 MockK를 권장합니다. MockKMockito 특정 @MockBean및 @SpyBean주석 과 동등한 것이 필요한 경우 유사 및 주석을 제공하는 SpringMockK를 사용할 수 있습니다 .@MockkBean@SpykBean

10.7. 자원

10.7.1. 추가 자료

• Kotlin 언어 참조
• Kotlin Slack (전용 #spring 채널 포함)
• spring및 kotlin태그가 있는 스택 오버플로
• 브라우저에서 Kotlin 사용해 보기
• 코틀린 블로그
• 멋진 코틀린
• 자습서: Spring Boot 및 Kotlin을 사용하여 웹 애플리케이션 구축
• Kotlin으로 Spring Boot 애플리케이션 개발
• Kotlin, Spring Boot 및 PostgreSQL을 사용한 지리정보 메신저
• Spring Framework 5.0에서 Kotlin 지원 소개
• Spring Framework 5 Kotlin API, 기능적 방식

10.7.2. 예

• spring-boot-kotlin-demo : 일반 Spring Boot + Spring Data JPA 프로젝트
• mixit : Spring Boot 2 + WebFlux + Reactive Spring Data MongoDB
• spring-kotlin-fullstack : JavaScript 또는 TypeScript 대신 프런트엔드용 Kotlin2js를 사용하는 WebFlux Kotlin 풀스택 예제
• spring-petclinic-kotlin : Spring PetClinic 샘플 애플리케이션의 Kotlin 버전
• spring-kotlin-deepdive : Boot 1.0 + Java에서 Boot 2.0 + Kotlin으로의 단계별 마이그레이션
• spring-boot-coroutines-demo : 코루틴 샘플 프로젝트

11. 다음에 읽을 내용

이 섹션에서 설명하는 클래스에 대해 자세히 알아보려면 Spring Boot API 설명서를 참조하거나 소스 코드를 직접 찾아볼 수 있습니다 . 특정 질문이 있는 경우 방법 섹션을 참조하세요.

Spring Boot의 핵심 기능에 익숙하다면 계속해서 프로덕션 준비 기능 에 대해 읽을 수 있습니다 .

 

출처

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.developing-auto-configuration