스프링 부트 #9. “How-to” Guides (2)

9.8. 벌채 반출

Spring Boot는 일반적으로 Spring Framework의 spring-jcl모듈에서 제공하는 Commons Logging API를 제외하고 필수 로깅 종속성이 없습니다 . Logback 을 사용하려면 로그 백과spring-jcl 클래스 경로에 포함시켜야합니다 . 가장 간단한 방법은 스타터를 이용하는 것입니다 spring-boot-starter-logging. 웹 응용 프로그램의 spring-boot-starter-web경우 로깅 스타터에 전 이적으로 의존하기 때문에 필요합니다 . Maven을 사용하는 경우 다음 종속성이 로깅을 추가합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Spring Boot에는 LoggingSystem클래스 경로의 내용을 기반으로 로깅을 구성하려는 추상화가 있습니다. Logback을 사용할 수 있으면 이것이 첫 번째 선택입니다.

로깅에 필요한 유일한 변경 사항이 다양한 로거의 레벨을 설정하는 것이라면 application.properties다음 예제와 같이 "logging.level"접 두부를 사용하여 이를 수행 할 수 있습니다 .

logging.level.org.springframework.web=DEBUG
logging.level.org.hibernate=ERROR

"logging.file.name"을 사용하여 콘솔 외에 로그를 쓸 파일의 위치를 ​​설정할 수도 있습니다.

로깅 시스템의보다 세밀한 설정을 구성하려면 해당 시스템에서 지원하는 기본 구성 형식을 사용해야합니다 LoggingSystem. 기본적으로 Spring Boot는 시스템의 기본 위치 (예 : classpath:logback.xmlLogback) 에서 기본 구성을 선택 하지만 logging.config속성 을 사용하여 구성 파일의 위치를 ​​설정할 수 있습니다 .

9.8.1. 로깅을위한 로그 백 구성

로 수행 할 수있는 것 이상의 로그 백에 사용자 정의를 적용해야하는 경우 application.properties표준 로그 백 구성 파일을 추가해야합니다. logback.xml로그 백을 위해 클래스 경로의 루트에 파일을 추가 할 수 있습니다 . Spring Boot Logback 확장logback-spring.xml 을 사용하려는 경우 에도 사용할 수 있습니다 .

로그 백 문서에는 구성 에 대해 자세히 설명 하는 전용 섹션이 있습니다 .

스프링 부트는 included자신이 구성한 다양한 로그 백 구성을 제공 합니다. 여기에는 일반적인 스프링 부트 규칙을 다시 적용 할 수 있도록 설계되었습니다.

다음 파일이 제공됩니다 org/springframework/boot/logging/logback/.

• defaults.xml -변환 규칙, 패턴 속성 및 공통 로거 구성을 제공합니다.
• console-appender.xml-를 ConsoleAppender사용하여를 추가합니다 CONSOLE_LOG_PATTERN.
• file-appender.xml- 추가 RollingFileAppender를 사용 FILE_LOG_PATTERN하고 ROLLING_FILE_NAME_PATTERN와 적절한 설정을.

또한 base.xml이전 버전의 Spring Boot와의 호환성을 위해 레거시 파일이 제공됩니다.

일반적인 사용자 정의 logback.xml파일은 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    <include resource="org/springframework/boot/logging/logback/console-appender.xml" />
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
    </root>
    <logger name="org.springframework.web" level="DEBUG"/>
</configuration>

로그 백 구성 파일은 또한 LoggingSystem작성을 담당 하는 시스템 특성을 사용할 수도 있습니다.

• ${PID}: 현재 프로세스 ID
• ${LOG_FILE}: logging.file.nameBoot의 외부 구성에서 설정 되었는지 여부
• ${LOG_PATH}: logging.file.path부트의 외부 구성에 로그 파일이있는 디렉토리를 나타내는 지 여부가 설정되었는지 여부
• ${LOG_EXCEPTION_CONVERSION_WORD}: logging.exception-conversion-wordBoot의 외부 구성에서 설정 되었는지 여부
• ${ROLLING_FILE_NAME_PATTERN}: logging.pattern.rolling-file-nameBoot의 외부 구성에서 설정 되었는지 여부

Spring Boot는 또한 사용자 정의 로그 백 변환기를 사용하여 콘솔에서 로그 파일이 아닌 멋진 ANSI 색상 터미널 출력을 제공합니다. 예 CONSOLE_LOG_PATTERN는 defaults.xml구성 에서를 참조하십시오 .

Groovy가 클래스 경로에있는 경우 로그 백도 구성 할 수 있어야합니다 logback.groovy. 있는 경우이 설정이 우선합니다.

스프링 확장은 Groovy 구성에서 지원되지 않습니다. 모든 logback-spring.groovy파일은 감지되지 않습니다.

파일 전용 출력을위한 로그 백 구성

콘솔 로깅을 비활성화하고 파일에만 출력을 쓰 려면 다음 예제와 같이 logback-spring.xml가져 file-appender.xml오지만 가져 오지 않는 사용자 지정 이 필요합니다 console-appender.xml.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml" />
    <property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}/}spring.log}"/>
    <include resource="org/springframework/boot/logging/logback/file-appender.xml" />
    <root level="INFO">
        <appender-ref ref="FILE" />
    </root>
</configuration>

다음 예제와 같이에 추가 logging.file.name해야합니다 application.properties.

logging.file.name=myapplication.log

9.8.2. 로깅을위한 Log4j 구성

Spring Boot는 클래스 경로에있는 경우 로깅 구성을 위해 Log4j 2 를 지원합니다 . 종속성을 조립하기 위해 스타터를 사용하는 경우 Logback을 제외하고 대신 log4j 2를 포함시켜야합니다. 스타터를 사용하지 않는 경우 spring-jclLog4j 2 외에 (적어도) 제공해야합니다 .

가장 간단한 경로는 아마도 초보자를 통하는 것입니다. 비록 제외와 함께 약간의 흔들림이 필요합니다. 다음 예제는 Maven에서 스타터를 설정하는 방법을 보여줍니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

다음 예제는 Gradle에서 스타터를 설정하는 한 가지 방법을 보여줍니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-log4j2'
}

configurations {
    all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
    }
}

Log4j 스타터는 일반적인 로깅 요구 사항 (예 : Tomcat을 사용 java.util.logging하지만 Log4j 2를 사용하여 출력 구성)에 대한 종속성을 모 읍니다 .

사용하여 수행 된 디버그 로깅 java.util.logging이 Log4j 2로 라우트되도록 하려면 시스템 특성을 로 설정하여 JDK 로깅 어댑터 를 구성 하십시오 . java.util.logging.managerorg.apache.logging.log4j.jul.LogManager

YAML 또는 JSON을 사용하여 Log4j 2 구성

기본 XML 구성 형식 외에도 Log4j 2는 YAML 및 JSON 구성 파일도 지원합니다. 대체 구성 파일 형식을 사용하도록 Log4j 2를 구성하려면 다음 예와 같이 클래스 파일에 적절한 종속성을 추가하고 선택한 파일 형식과 일치하도록 구성 파일의 이름을 지정하십시오.

체재	의존성	파일명
YAML	com.fasterxml.jackson.core:jackson-databind + com.fasterxml.jackson.dataformat:jackson-dataformat-yaml	log4j2.yaml + log4j2.yml
JSON	com.fasterxml.jackson.core:jackson-databind	log4j2.json + log4j2.jsn

9.9. 데이터 접근

Spring Boot에는 데이터 소스 작업을위한 여러 스타터가 포함되어 있습니다. 이 섹션에서는 이와 관련된 질문에 답변합니다.

9.9.1. 사용자 정의 데이터 소스 구성

자신을 구성하려면 구성 에서 해당 유형을 DataSource정의 @Bean하십시오. Spring Boot는 DataSource데이터베이스 초기화를 포함하여 필요한 곳을 재사용합니다 . 일부 설정을 외부화해야하는 경우 DataSource환경에 바인딩 할 수 있습니다 (“ 타사 구성 ”참조).

다음 예제는 Bean에서 데이터 소스를 정의하는 방법을 보여줍니다.

@Bean
@ConfigurationProperties(prefix="app.datasource")
public DataSource dataSource() {
    return new FancyDataSource();
}

다음 예제는 특성을 설정하여 데이터 소스를 정의하는 방법을 보여줍니다.

app.datasource.url=jdbc:h2:mem:mydb
app.datasource.username=sa
app.datasource.pool-size=30

FancyDataSourceURL, 사용자 이름 및 풀 크기에 대한 일반 JavaBean 특성이 있다고 가정하면 이러한 설정은 DataSource다른 구성 요소에서 사용 가능하게 되기 전에 자동으로 바인드됩니다 . 정기적 인 데이터베이스 초기화 도 수행됩니다 (따라서 관련 하위 세트를 spring.datasource.*사용자 정의 구성과 함께 계속 사용할 수 있음).

Spring Boot는 또한 DataSourceBuilder표준 데이터 소스 중 하나를 만드는 데 사용할 수 있는 유틸리티 빌더 클래스를 제공 합니다 (클래스 경로에있는 경우). 빌더는 클래스 경로에서 사용 가능한 것을 기반으로 사용할 것을 감지 할 수 있습니다. 또한 JDBC URL을 기반으로 드라이버를 자동 감지합니다.

다음 예제는 다음을 사용하여 데이터 소스를 작성하는 방법을 보여줍니다 DataSourceBuilder.

@Bean
@ConfigurationProperties("app.datasource")
public DataSource dataSource() {
    return DataSourceBuilder.create().build();
}

이 앱을 실행하려면 DataSource연결 정보 만 있으면됩니다. 풀별 설정도 제공 할 수 있습니다. 자세한 내용은 런타임에 사용될 구현을 확인하십시오.

다음 예제는 특성을 설정하여 JDBC 데이터 소스를 정의하는 방법을 보여줍니다.

app.datasource.url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.pool-size=30

그러나 캐치가 있습니다. 연결 풀의 실제 유형이 노출되지 않기 때문에 사용자 정의에 대한 메타 데이터에 키가 생성 DataSource되지 않으며 IDE에서 DataSource인터페이스를 사용할 수 없으므로 ( 인터페이스에 속성이 표시되지 않기 때문에) 완료 할 수 없습니다. 또한 클래스 경로에 Hikari가 있으면 Hikari에는 url속성 이 없지만 속성 이 있기 때문에이 기본 설정이 작동하지 않습니다 jdbcUrl. 이 경우 다음과 같이 구성을 다시 작성해야합니다.

app.datasource.jdbc-url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.maximum-pool-size=30

연결 풀이 강제로가 아닌 전용 구현을 사용하고 리턴하도록하여이를 해결할 수 있습니다 DataSource. 런타임에는 구현을 변경할 수 없지만 옵션 목록은 명시 적입니다.

다음 예제는 HikariDataSourcewith를 작성하는 방법을 보여줍니다 DataSourceBuilder.

@Bean
@ConfigurationProperties("app.datasource")
public HikariDataSource dataSource() {
    return DataSourceBuilder.create().type(HikariDataSource.class).build();
}

DataSourcePropertiesURL이 제공되지 않는 경우 적절한 사용자 이름과 비밀번호가 포함 된 기본 내장 데이터베이스를 제공하여 사용자를 위해 더 많은 것을 진행할 수도 있습니다 . 객체 DataSourceBuilder의 상태에서 쉽게 초기화 DataSourceProperties할 수 있으므로 Spring Boot가 자동으로 생성하는 DataSource를 삽입 할 수도 있습니다. 그러나, 두 개의 네임 스페이스로 구성을 나눌 것입니다 : url, username, password, type,과 driver에 spring.datasource및 사용자 정의 네임 스페이스에 나머지 ( app.datasource). 이를 피하기 위해 DataSourceProperties다음 예제와 같이 사용자 정의 네임 스페이스에서 사용자 정의 를 재정의 할 수 있습니다 .

@Bean
@Primary
@ConfigurationProperties("app.datasource")
public DataSourceProperties dataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@ConfigurationProperties("app.datasource.configuration")
public HikariDataSource dataSource(DataSourceProperties properties) {
    return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

이 설정은 코드에서 전용 연결 풀이 선택되고 해당 설정이 하위 네임 스페이스에 노출된다는 점을 제외하고 기본적으로 Spring Boot의 기능과 동기화 됩니다 app.datasource.configuration. 때문에 DataSourceProperties의 관리 취하고있다 url/의 jdbcUrl당신을 위해 번역을 다음과 같이 구성 할 수 있습니다 :

app.datasource.url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.configuration.maximum-pool-size=30

Spring Boot는 Hikari 특정 설정을에 노출합니다 spring.datasource.hikari. 이 예는 configuration여러 데이터 소스 구현을 지원하지 않으므로 보다 일반적인 하위 네임 스페이스를 사용합니다.

사용자 정의 구성은 Hikari와 함께 선택하므로 app.datasource.type효과가 없습니다. 실제로 빌더는 사용자가 설정할 수있는 값으로 초기화 된 다음에 대한 호출로 대체됩니다 .type().

자세한 내용 은“스프링 부팅 기능”섹션의“ 데이터 소스 구성 ”및 DataSourceAutoConfiguration클래스를 참조하십시오.

9.9.2. 두 개의 데이터 소스 구성

여러 데이터 소스를 구성해야하는 경우 이전 섹션에서 설명한 것과 동일한 트릭을 적용 할 수 있습니다. 그러나 다양한 자동 구성을 통해 유형별로 하나씩 얻을 수 있기 때문에 DataSource인스턴스 중 하나를로 표시해야합니다 @Primary.

자신 DataSource만을 만들면 자동 구성이 취소됩니다. 다음 예에서는 기본 데이터 소스에서 자동 구성이 제공하는 것과 동일한 기능 세트를 제공합니다.

@Bean
@Primary
@ConfigurationProperties("app.datasource.first")
public DataSourceProperties firstDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@Primary
@ConfigurationProperties("app.datasource.first.configuration")
public HikariDataSource firstDataSource() {
    return firstDataSourceProperties().initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

@Bean
@ConfigurationProperties("app.datasource.second")
public BasicDataSource secondDataSource() {
    return DataSourceBuilder.create().type(BasicDataSource.class).build();
}

firstDataSourceProperties@Primary데이터베이스 이니셜 라이저 기능이 사본을 사용하도록 플래그를 지정 해야합니다 (이니셜 라이저를 사용하는 경우).

두 데이터 소스 모두 고급 사용자 지정을 위해 바인딩되었습니다. 예를 들어 다음과 같이 구성 할 수 있습니다.

app.datasource.first.url=jdbc:mysql://localhost/first
app.datasource.first.username=dbuser
app.datasource.first.password=dbpass
app.datasource.first.configuration.maximum-pool-size=30

app.datasource.second.url=jdbc:mysql://localhost/second
app.datasource.second.username=dbuser
app.datasource.second.password=dbpass
app.datasource.second.max-total=30

DataSource다음 예제와 같이 동일한 개념을 보조에도 적용 할 수 있습니다 .

@Bean
@Primary
@ConfigurationProperties("app.datasource.first")
public DataSourceProperties firstDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@Primary
@ConfigurationProperties("app.datasource.first.configuration")
public HikariDataSource firstDataSource() {
    return firstDataSourceProperties().initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

@Bean
@ConfigurationProperties("app.datasource.second")
public DataSourceProperties secondDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@ConfigurationProperties("app.datasource.second.configuration")
public BasicDataSource secondDataSource() {
    return secondDataSourceProperties().initializeDataSourceBuilder().type(BasicDataSource.class).build();
}

앞의 예제는 Spring Boot가 자동 구성에 사용하는 것과 동일한 논리를 사용하여 사용자 정의 네임 스페이스에 두 개의 데이터 소스를 구성합니다. 각 configuration하위 네임 스페이스는 선택한 구현을 기반으로 고급 설정을 제공합니다.

9.9.3. 스프링 데이터 리포지토리 사용

Spring Data는 @Repository다양한 특징 의 인터페이스 구현을 생성 할 수 있습니다 . Spring Boot는 클래스 @Repositories의 동일한 패키지 (또는 하위 패키지)에 포함되어 있으면 모든 것을 처리합니다 @EnableAutoConfiguration.

많은 애플리케이션에서 필요한 것은 클래스 패스에 올바른 Spring Data 의존성을 두는 것입니다. a가있다 spring-boot-starter-data-jpaJPA를 들어, spring-boot-starter-data-mongodb시작하려면 등 MongoDB를, 들어, 처리 할 수있는 몇 가지 저장소 인터페이스를 만들 @Entity개체를.

Spring Boot는 찾은 것을 @Repository기반으로 정의 의 위치를 ​​추측하려고 시도합니다 @EnableAutoConfiguration. 더 많은 제어권을 얻으려면 @EnableJpaRepositories주석을 사용하십시오 (Spring Data JPA에서).

스프링 데이터에 대한 자세한 내용은 스프링 데이터 프로젝트 페이지를 참조하십시오 .

9.9.4. 스프링 구성에서 @Entity 정의 분리

Spring Boot는 찾은 것을 @Entity기반으로 정의 의 위치를 ​​추측하려고 시도합니다 @EnableAutoConfiguration. 더 많은 제어권을 얻으려면 @EntityScan다음 예제와 같이 주석을 사용할 수 있습니다 .

@Configuration(proxyBeanMethods = false)
@EnableAutoConfiguration
@EntityScan(basePackageClasses=City.class)
public class Application {

    //...

}

9.9.5. JPA 속성 구성

Spring Data JPA는 이미 벤더 독립적 인 구성 옵션 (예 : SQL 로깅 용 옵션)을 제공하고 있으며 Spring Boot는 이러한 옵션과 Hibernate에 대한 외부 구성 속성으로 몇 가지 옵션을 제공합니다. 일부는 상황에 따라 자동으로 감지되므로 설정할 필요가 없습니다.

는 spring.jpa.hibernate.ddl-auto런타임 조건에 따라, 그것은 다른 기본값을 가지고 있기 때문에, 특별한 경우이다. 내장 데이터베이스가 사용되고 스키마 관리자 (예 : Liquibase 또는 Flyway)에서를 처리하지 않는 DataSource경우 기본값은 create-drop입니다. 다른 모든 경우에는 기본값이 none입니다.

사용할 방언은 JPA 제공자가 감지합니다. 방언을 직접 설정하려면 spring.jpa.database-platform속성을 설정하십시오 .

가장 일반적인 설정 옵션은 다음 예에 나와 있습니다.

spring.jpa.hibernate.naming.physical-strategy = com.example.MyPhysicalNamingStrategy
spring.jpa.show-sql = true

또한 spring.jpa.properties.*로컬의 EntityManagerFactory작성 시 모든 특성은 일반 JPA 특성 (접 두부가 제거 된)으로 전달됩니다 .

아래에 정의 된 이름이 spring.jpa.properties.*JPA 제공자가 예상 한 이름 과 정확히 일치 하는지 확인해야합니다 . Spring Boot는 이러한 항목에 대해 어떤 종류의 완화 된 바인딩도 시도하지 않습니다. 예를 들어, 최대 절전 모드의 배치 크기를 구성하려면을 사용해야합니다 spring.jpa.properties.hibernate.jdbc.batch_size. batchSize또는 과 같은 다른 양식을 사용하면 batch-size최대 절전 모드에서 설정이 적용되지 않습니다.

Hibernate 프로퍼티에 고급 커스터마이제이션을 적용해야하는 경우, HibernatePropertiesCustomizer를 생성하기 전에 호출 될 Bean을 등록하는 것을 고려 하십시오 EntityManagerFactory. 이것은 자동 구성에 의해 적용되는 것보다 우선합니다.

9.9.6. 최대 절전 이름 지정 전략 구성

Hibernate는 두 가지 다른 이름 지정 전략 을 사용 하여 객체 모델에서 해당 데이터베이스 이름으로 이름을 매핑합니다. 실제 및 내재 된 전략 구현의 완전한 클래스 이름은 spring.jpa.hibernate.naming.physical-strategy및 spring.jpa.hibernate.naming.implicit-strategy특성을 각각 설정하여 구성 할 수 있습니다 . 경우 또는, ImplicitNamingStrategy또는 PhysicalNamingStrategy콩 애플리케이션 컨텍스트에서 사용할 수있는, 최대 절전 모드는 자동으로 사용하도록 구성됩니다.

기본적으로 Spring Boot는로 물리적 이름 지정 전략을 구성합니다 SpringPhysicalNamingStrategy. 이 구현은 최대 절전 모드 4와 동일한 테이블 구조를 제공합니다. 모든 점은 밑줄로, 낙타 케이싱은 밑줄로 바뀝니다. 기본적으로 모든 테이블 이름은 소문자로 생성되지만 스키마에 필요한 경우 해당 플래그를 재정의 할 수 있습니다.

예를 들어 TelephoneNumber엔터티가 telephone_number테이블에 매핑됩니다 .

대신 Hibernate 5의 기본값을 사용하려면 다음 속성을 설정하십시오 :

spring.jpa.hibernate.naming.physical-strategy = org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

또는 다음 Bean을 구성 할 수 있습니다.

@Bean
public PhysicalNamingStrategy physicalNamingStrategy() {
    return new PhysicalNamingStrategyStandardImpl();
}

참조 HibernateJpaAutoConfiguration및 JpaBaseConfiguration자세한 내용은.

9.9.7. 최대 절전 모드 2 차 캐싱 구성

다양한 캐시 공급자에 대해 최대 절전 모드 2 차 캐시 를 구성 할 수 있습니다. 캐시 공급자를 다시 조회하도록 Hibernate를 구성하는 대신, 가능할 때마다 컨텍스트에서 사용 가능한 것을 제공하는 것이 좋습니다.

JCache를 사용하는 경우 매우 쉽습니다. 먼저 org.hibernate:hibernate-jcache클래스 경로에서 사용할 수 있는지 확인하십시오 . 그런 다음, HibernatePropertiesCustomizer다음 예제와 같이 Bean을 추가하십시오 .

@Configuration(proxyBeanMethods = false)
public class HibernateSecondLevelCacheExample {

    @Bean
    public HibernatePropertiesCustomizer hibernateSecondLevelCacheCustomizer(JCacheCacheManager cacheManager) {
        return (properties) -> properties.put(ConfigSettings.CACHE_MANAGER, cacheManager.getCacheManager());
    }

}

이 커 스터 마이 CacheManager저는 Hibernate가 어플리케이션 이 사용하는 것과 동일하게 사용하도록 설정 합니다. 별도의 CacheManager인스턴스 를 사용할 수도 있습니다 . 자세한 내용 은 Hibernate 사용 설명서를 참조하십시오 .

9.9.8. 최대 절전 모드 구성 요소에서 종속성 주입 사용

기본적으로 Spring Boot 는 변환기와 엔티티 리스너가 규칙적인 의존성 주입을 사용할 수 있도록 BeanContainer사용 하는 구현을 등록합니다 BeanFactory.

속성 HibernatePropertiesCustomizer을 제거하거나 변경하는를 등록하여이 동작을 비활성화하거나 조정할 수 있습니다 hibernate.resource.beans.container.

9.9.9. 사용자 지정 EntityManagerFactory 사용

의 구성을 완전히 제어하려면 'entityManagerFactory'라는 이름 EntityManagerFactory을 추가해야합니다 @Bean. Spring Boot 자동 구성은 해당 유형의 Bean이있을 때 엔티티 관리자를 끕니다.

9.9.10. 두 개의 EntityManager 사용

기본값이 EntityManagerFactory제대로 작동 하더라도 새 값을 정의해야합니다. 그렇지 않으면 해당 유형의 두 번째 Bean이 있으면 기본값이 꺼집니다. 쉬운 작업을 위해 EntityManagerBuilderSpring Boot에서 제공 하는 편리한 기능을 사용할 수 있습니다 . 또는 LocalContainerEntityManagerFactoryBean다음 예제와 같이 Spring ORM 에서 직접 사용할 수 있습니다 .

// add two data sources configured as above

@Bean
public LocalContainerEntityManagerFactoryBean customerEntityManagerFactory(
        EntityManagerFactoryBuilder builder) {
    return builder
            .dataSource(customerDataSource())
            .packages(Customer.class)
            .persistenceUnit("customers")
            .build();
}

@Bean
public LocalContainerEntityManagerFactoryBean orderEntityManagerFactory(
        EntityManagerFactoryBuilder builder) {
    return builder
            .dataSource(orderDataSource())
            .packages(Order.class)
            .persistenceUnit("orders")
            .build();
}

Bean을 LocalContainerEntityManagerFactoryBean직접 작성하면 자동 구성 작성 중에 적용된 모든 사용자 정의 LocalContainerEntityManagerFactoryBean가 유실됩니다. 예를 들어, 최대 절전 모드의 경우 spring.jpa.hibernate접두사 아래의 속성은에 자동으로 적용되지 않습니다 LocalContainerEntityManagerFactoryBean. 이름 지정 전략 또는 DDL 모드와 같은 항목을 구성하기 위해 이러한 특성에 의존하는 경우 LocalContainerEntityManagerFactoryBeanBean을 작성할 때이를 명시 적으로 구성해야합니다 . 반면, 자동 구성 을 사용하여 Bean 을 빌드하는 EntityManagerFactoryBuilder경우를 통해 지정된 자동 구성에 적용되는 특성 spring.jpa.properties이 자동으로 적용됩니다 . EntityManagerFactoryBuilderLocalContainerEntityManagerFactoryBean

위의 구성은 거의 자체적으로 작동합니다. 그림을 완성하려면 TransactionManagers두 구성도 구성해야합니다 EntityManagers. 이 중 하나를로 표시 @Primary하면 기본적 JpaTransactionManager으로 Spring Boot에서 선택할 수 있습니다 . 다른 하나는 새 인스턴스에 명시 적으로 주입되어야합니다. 또는 둘 다에 걸쳐있는 JTA 트랜잭션 관리자를 사용할 수 있습니다.

스프링 데이터를 사용하는 경우 @EnableJpaRepositories다음 예제와 같이 적절히 구성해야합니다 .

@Configuration(proxyBeanMethods = false)
@EnableJpaRepositories(basePackageClasses = Customer.class,
        entityManagerFactoryRef = "customerEntityManagerFactory")
public class CustomerConfiguration {
    ...
}

@Configuration(proxyBeanMethods = false)
@EnableJpaRepositories(basePackageClasses = Order.class,
        entityManagerFactoryRef = "orderEntityManagerFactory")
public class OrderConfiguration {
    ...
}

9.9.11. 전통적인 persistence.xml 파일 사용

Spring Boot는 META-INF/persistence.xml기본적으로 a 를 검색하거나 사용하지 않습니다 . traditional을 사용 하려면 ID 유형 이 'entityManagerFactory'인 persistence.xml고유 @Bean유형 을 정의 LocalEntityManagerFactoryBean하고 지속성 단위 이름을 설정해야합니다.

JpaBaseConfiguration기본 설정을 참조하십시오 .

9.9.12. Spring Data JPA 및 Mongo 저장소 사용

Spring Data JPA와 Spring Data Mongo는 모두 자동으로 Repository구현을 생성 할 수 있습니다. 둘 다 클래스 경로에 있으면 스프링 부트에 생성 할 리포지토리를 알리기 위해 추가 구성을 수행해야 할 수도 있습니다. 가장 명확한 방법은 표준 스프링 데이터 @EnableJpaRepositories와 @EnableMongoRepositories주석 을 사용하고 Repository인터페이스 의 위치를 ​​제공하는 것 입니다.

외부 구성에서 자동 구성 저장소를 켜고 끄는 데 사용할 수있는 플래그 ( spring.data.*.repositories.enabled및 spring.data.*.repositories.type) 도 있습니다. 예를 들어 Mongo 저장소를 끄고 여전히 자동 구성을 사용하려는 경우에 유용합니다 MongoTemplate.

다른 자동 구성 스프링 데이터 리포지토리 유형 (Elasticsearch, Solr 및 기타)에 대해 동일한 장애 및 동일한 기능이 존재합니다. 그것들과 함께 작업하려면 주석과 플래그의 이름을 적절히 변경하십시오.

9.9.13. 스프링 데이터의 웹 지원 커스터마이징

Spring Data는 웹 애플리케이션에서 Spring Data 리포지토리 사용을 단순화하는 웹 지원을 제공합니다. Spring Boot는 spring.data.web네임 스페이스에 구성을 사용자 정의하기위한 속성을 제공 합니다. Spring Data REST를 사용하는 경우 spring.data.rest네임 스페이스 의 속성을 대신 사용해야합니다 .

9.9.14. 스프링 데이터 리포지토리를 REST 엔드 포인트로 노출

Spring RepositoryMVC가 애플리케이션에 대해 활성화 된 경우 Spring Data REST는 구현을 REST 엔드 포인트로 표시 할 수 있습니다 .

Spring Boot는 spring.data.rest을 커스터마이즈하는 유용한 속성 세트를 네임 스페이스 에서 공개 합니다 RepositoryRestConfiguration. 추가 사용자 정의를 제공해야하는 경우 RepositoryRestConfigurerBean을 사용해야합니다 .

custom에 주문을 지정하지 않으면 RepositoryRestConfigurer하나의 Spring Boot가 내부적으로 사용 된 후에 실행됩니다. 주문을 지정해야하는 경우 주문이 0보다 큰지 확인하십시오.

9.9.15. JPA에서 사용하는 구성 요소 구성

JPA가 사용하는 구성 요소를 구성하려면 JPA 전에 구성 요소가 초기화되었는지 확인해야합니다. 컴포넌트가 자동 설정되면 Spring Boot가이를 처리합니다. 예를 들어, Flyway가 자동 구성되면 Hibernate는 Flyway가 데이터베이스를 사용하기 전에 Flyway가 데이터베이스를 초기화 할 수 있도록 Flyway에 의존하도록 구성됩니다.

구성 요소를 직접 구성하는 EntityManagerFactoryDependsOnPostProcessor경우 필요한 종속성을 설정하는 편리한 방법으로 하위 클래스를 사용할 수 있습니다 . 예를 들어, Elasticsearch를 인덱스 관리자로 사용하여 최대 절전 모드 검색을 사용하는 경우 다음 예제와 같이 모든 EntityManagerFactoryBean이 elasticsearchClientBean 에 종속되도록 구성되어야합니다 .

/**
 * {@link EntityManagerFactoryDependsOnPostProcessor} that ensures that
 * {@link EntityManagerFactory} beans depend on the {@code elasticsearchClient} bean.
 */
@Component
static class ElasticsearchEntityManagerFactoryDependsOnPostProcessor
        extends EntityManagerFactoryDependsOnPostProcessor {

    ElasticsearchEntityManagerFactoryDependsOnPostProcessor() {
        super("elasticsearchClient");
    }

}

9.9.16. 두 개의 데이터 소스로 jOOQ 구성

여러 데이터 소스와 함께 jOOQ를 사용해야하는 경우 DSLContext각각에 대해 고유 한 데이터를 작성해야합니다 . 자세한 내용은 JooqAutoConfiguration 을 참조하십시오.

특히, JooqExceptionTranslator및 SpringTransactionProvider자동 구성이 단일로 무엇 유사한 기능을 제공하기 위해 재사용 될 수있다 DataSource.

9.10. 데이터베이스 초기화

스택에 따라 SQL 데이터베이스를 다른 방식으로 초기화 할 수 있습니다. 물론 데이터베이스가 별도의 프로세스 인 경우 수동으로 수행 할 수도 있습니다. 스키마 생성에는 단일 메커니즘을 사용하는 것이 좋습니다.

9.10.1. JPA를 사용하여 데이터베이스 초기화

JPA에는 DDL 생성 기능이 있으며 데이터베이스에 대해 시작시 실행되도록 설정할 수 있습니다. 이것은 두 가지 외부 속성을 통해 제어됩니다.

• spring.jpa.generate-ddl (부울)은 기능을 켜고 끄며 공급 업체에 독립적입니다.
• spring.jpa.hibernate.ddl-auto(enum)은보다 세밀한 방식으로 동작을 제어하는 ​​최대 절전 기능입니다. 이 기능은이 안내서의 뒷부분에 자세히 설명되어 있습니다.

9.10.2. 최대 절전 모드를 사용하여 데이터베이스 초기화

당신은 설정할 수 있습니다 spring.jpa.hibernate.ddl-auto명시 적으로 표준 최대 절전 모드 속성 값은 none, validate, update, create,와 create-drop. Spring Boot는 데이터베이스가 내장되어 있다고 생각하는지 여부에 따라 기본값을 선택합니다. create-drop스키마 관리자가 감지되지 않았거나 none다른 모든 경우에 기본값 입니다. 내장 데이터베이스는 Connection유형 을보고 감지됩니다 . hsqldb, h2,와 derby내장, 그리고 다른 사람은 아니다. 인 메모리에서 '실제'데이터베이스로 전환 할 때 새 플랫폼에서 테이블 및 데이터의 존재에 대해 가정하지 않는 것에주의하십시오. ddl-auto데이터베이스를 초기화하려면 명시 적 으로 설정 하거나 다른 메커니즘 중 하나를 사용해야합니다.

org.hibernate.SQL로거를 사용 하여 스키마 작성을 출력 할 수 있습니다 . 디버그 모드 를 활성화하면 자동으로 수행 됩니다 .

또한 import.sql클래스 패스의 루트에 이름이 지정된 파일 은 Hibernate가 스키마를 처음부터 생성하는 경우 (즉, ddl-auto속성이 create또는 로 설정된 경우) 시작시 실행됩니다 create-drop. 이것은주의를 기울이지 만 프로덕션 환경에서 클래스 경로에 포함하고 싶지 않은 경우 데모 및 테스트에 유용 할 수 있습니다. 그것은 최대 절전 기능입니다 (Spring과 관련이 없습니다).

9.10.3. 기본 SQL 스크립트를 사용하여 데이터베이스 초기화

Spring Boot는 자동으로 스키마 (DDL 스크립트)를 생성 DataSource하고 초기화합니다 (DML 스크립트). 표준 루트 클래스 경로 위치 schema.sql및 data.sql에서 각각 SQL을로드합니다 . 또한 Spring Boot는 schema-${platform}.sql및 data-${platform}.sql파일 (있는 경우)을 처리합니다 . 여기서 platform값은 spring.datasource.platform입니다. 필요한 경우 데이터베이스 별 스크립트로 전환 할 수 있습니다. 예를 들어, 데이터베이스 공급 업체 이름으로 설정하도록 선택할 수 있습니다 ( hsqldb, h2, oracle, mysql, postgresql, 등).

기본 SQL 스크립트 만 사용하면 Spring Boot는 내장 스키마를 자동으로 생성합니다 DataSource. 이 동작은 spring.datasource.initialization-mode속성 을 사용하여 사용자 지정할 수 있습니다 . 예를 들어, DataSource유형에 관계없이 항상 초기화하려는 경우 : spring.datasource.initialization-mode = 항상 JPA 기반 앱에서 Hibernate가 스키마를 만들거나 사용하도록 선택할 schema.sql수 있지만 둘 다 수행 할 수는 없습니다. 를 사용하는 spring.jpa.hibernate.ddl-auto경우 비활성화하십시오 schema.sql. spring.jpa.hibernate.ddl-auto = 없음 당신이 사용하는 경우 높은 수준의 데이터베이스 마이그레이션 도구를 , 이동 경로 또는 Liquibase처럼 작성하고 스키마를 초기화하는 기본 SQL 스크립트를 사용할 수 없습니다. 이 상황에서 schema.sqland data.sql가 있으면 무시됩니다. 데이터베이스 마이그레이션 도구를 사용하여 스키마 생성을 관리 할 수 ​​없으며 기본 SQL 스크립트를 사용하여 초기화 할 수 없습니다.

기본적으로 Spring Boot는 Spring JDBC 초기화 프로그램의 빠른 실패 기능을 활성화합니다. 즉, 스크립트에서 예외가 발생하면 응용 프로그램이 시작되지 않습니다. 을 설정하여 해당 동작을 조정할 수 있습니다 spring.datasource.continue-on-error.

9.10.4. R2DBC를 사용하여 데이터베이스 초기화

R2DBC를 사용하는 경우 일반 DataSource자동 구성이 취소되므로 위에서 설명한 옵션을 사용할 수 없습니다.

Spring Data R2DBC를 사용하는 경우 다음 예제와 같이 간단한 SQL 스크립트를 사용하여 시작시 데이터베이스를 초기화 할 수 있습니다.

@Configuration(proxyBeanMethods = false)
static class DatabaseInitializationConfiguration {

    @Autowired
    void initializeDatabase(ConnectionFactory connectionFactory) {
        ResourceLoader resourceLoader = new DefaultResourceLoader();
        Resource[] scripts = new Resource[] { resourceLoader.getResource("classpath:schema.sql"),
                resourceLoader.getResource("classpath:data.sql") };
        new ResourceDatabasePopulator(scripts).execute(connectionFactory).block();
    }

}

또는 마이그레이션 기간 동안 Flyway 또는 Liquibase 를 구성하여 구성 할 수 있습니다 DataSource. 이 두 라이브러리는을 설정하는 속성을 제공 url, username및 password데이터베이스의 마이그레이션.

이 옵션을 선택할 때 org.springframework:spring-jdbc여전히 필수 종속성입니다.

9.10.5. 스프링 배치 데이터베이스 초기화

Spring Batch를 사용하는 경우 가장 많이 사용되는 데이터베이스 플랫폼을위한 SQL 초기화 스크립트가 사전 패키지로 제공됩니다. Spring Boot는 데이터베이스 유형을 감지하고 시작할 때 해당 스크립트를 실행할 수 있습니다. 내장 데이터베이스를 사용하는 경우 기본적으로이 문제가 발생합니다. 다음 예제와 같이 모든 데이터베이스 유형에 대해이를 사용할 수 있습니다.

spring.batch.initialize-schema = 항상

을 설정하여 초기화를 명시 적으로 끌 수도 있습니다 spring.batch.initialize-schema=never.

9.10.6. 더 높은 수준의 데이터베이스 마이그레이션 도구 사용

Spring Boot는 두 가지 상위 레벨 마이그레이션 도구 인 Flyway 및 Liquibase를 지원 합니다.

시작시 Flyway 데이터베이스 마이그레이션 실행

시작할 때 Flyway 데이터베이스 마이그레이션을 자동으로 실행하려면 org.flywaydb:flyway-core클래스 경로에을 추가하십시오 .

일반적으로 마이그레이션은 '1'또는 '2_1'과 같이 밑줄로 구분 된 버전을 V<VERSION>__<NAME>.sql사용 <VERSION>하는 형태의 스크립트입니다 . 기본적으로이 디렉토리는이라는 디렉토리 classpath:db/migration에 있지만을 설정하여 해당 위치를 수정할 수 있습니다 spring.flyway.locations. 이것은 하나 이상의 쉼표로 구분 된 목록 classpath:또는 filesystem:위치. 예를 들어 다음 구성은 기본 클래스 경로 위치와 /opt/migration디렉토리 모두에서 스크립트를 검색합니다 .

spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration

{vendor}공급 업체별 스크립트를 사용하기 위해 특수 자리 표시자를 추가 할 수도 있습니다 . 다음을 가정하십시오.

spring.flyway.locations=classpath:db/migration/{vendor}

위의 구성은을 사용하는 대신 db/migration데이터베이스 유형 (예 : db/migration/mysqlMySQL) 에 따라 사용할 디렉토리를 설정합니다 . 지원되는 데이터베이스 목록은에서 사용할 수 있습니다 DatabaseDriver.

마이그레이션은 Java로 작성할 수도 있습니다. Flyway는를 구현하는 모든 Bean으로 자동 구성됩니다 JavaMigration.

FlywayPropertiesFlyway의 설정 대부분과 마이그레이션을 비활성화하거나 위치 확인을 끄는 데 사용할 수있는 추가 속성의 작은 집합을 제공합니다. 구성에 대한 추가 제어가 필요한 경우 FlywayConfigurationCustomizerBean 등록을 고려하십시오 .

Spring Boot Flyway.migrate()는 데이터베이스 마이그레이션을 수행하기 위해 호출 합니다. 더 많은 제어를 원하면 @Bean구현 하는 을 제공하십시오 FlywayMigrationStrategy.

Flyway는 SQL 및 Java 콜백을 지원합니다 . SQL 기반 콜백을 사용하려면 classpath:db/migration디렉토리에 콜백 스크립트를 배치하십시오 . Java 기반 콜백을 사용하려면를 구현하는 하나 이상의 Bean을 작성하십시오 Callback. 이러한 빈은에 자동으로 등록됩니다 Flyway. 을 사용 @Order하거나 구현 하여 주문할 수 있습니다 Ordered. 더 이상 사용되지 않는 FlywayCallback인터페이스 를 구현하는 Bean 도 감지 할 수 있지만 CallbackBean 과 함께 사용할 수 없습니다 .

기본적으로 Flyway 는 컨텍스트에서 ( @Primary) DataSource를 자동으로 연결하고 마이그레이션에 사용합니다. 다른를 사용하려는 경우 DataSource, 당신은 하나를 생성하고 표시 할 수 있습니다 @Bean로 @FlywayDataSource. 그렇게하고 두 개의 데이터 소스를 원하면 다른 데이터 소스를 작성하고로 표시하십시오 @Primary. 또는 외부 속성 DataSource을 설정 하여 Flyway의 네이티브 를 사용할 수 있습니다 spring.flyway.[url,user,password]. Flyway가 자체적으로 사용하도록 spring.flyway.url또는 설정 중 하나 입니다. 세 속성 중 하나가 설정되지 않은 경우 해당 속성 의 값 이 사용됩니다.spring.flyway.userDataSourcespring.datasource

Flyway를 사용하여 특정 시나리오에 대한 데이터를 제공 할 수도 있습니다. 예를 들어 테스트 별 마이그레이션을 배치 할 수 있으며 src/test/resources응용 프로그램에서 테스트를 시작할 때만 실행됩니다. 또한 프로파일 별 구성을 사용하여 spring.flyway.locations특정 마이그레이션이 특정 프로파일이 활성화 된 경우에만 실행되도록 사용자 정의 할 수 있습니다 . 예를 들어에서에서 application-dev.properties다음 설정을 지정할 수 있습니다.

spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration

해당 설정을 사용 dev/db/migration하면 dev프로파일이 활성화 된 경우에만 마이그레이션이 실행됩니다 .

시작시 Liquibase 데이터베이스 마이그레이션 실행

시작시 Liquibase 데이터베이스 마이그레이션을 자동으로 실행하려면 org.liquibase:liquibase-core클래스 경로 에을 추가하십시오 .

org.liquibase:liquibase-core클래스 경로에 를 추가하면 응용 프로그램 시작 중과 테스트 실행 전에 데이터베이스 마이그레이션이 기본적으로 실행됩니다. 이 동작은 spring.liquibase.enabled속성 을 사용 하여 main및 test구성 에서 다른 값을 설정 하여 사용자 지정할 수 있습니다 . 데이터베이스를 초기화하는 두 가지 방법 (예 : 응용 프로그램 시작을위한 Liquibase, 테스트 실행을위한 JPA)을 사용할 수 없습니다.

기본적으로 마스터 변경 로그는에서 읽지 만을 db/changelog/db.changelog-master.yaml설정하여 위치를 변경할 수 있습니다 spring.liquibase.change-log. Liquibase는 YAML 외에도 JSON, XML 및 SQL 변경 로그 형식도 지원합니다.

기본적으로 Liquibase 는 컨텍스트에서 ( @Primary) DataSource를 자동으로 연결하고 마이그레이션에 사용합니다. 다른를 사용해야하는 경우 DataSource, 당신은 하나를 생성하고 표시 할 수 있습니다 @Bean로 @LiquibaseDataSource. 그렇게하고 두 개의 데이터 소스를 원하면 다른 데이터 소스를 작성하고로 표시하십시오 @Primary. 또는 외부 속성 DataSource을 설정 하여 Liquibase의 네이티브 를 사용할 수 있습니다 spring.liquibase.[url,user,password]. spring.liquibase.url또는 spring.liquibase.userLiquibase가 자체적으로 사용하기에 충분한 또는 설정 DataSource. 세 속성 중 하나가 설정되지 않은 경우 해당 spring.datasource속성 의 값 이 사용됩니다.

LiquibaseProperties컨텍스트, 기본 스키마 및 기타와 같은 사용 가능한 설정에 대한 자세한 내용 을 참조하십시오 .

9.11. 메시징

스프링 부트는 메시징을 포함한 수많은 스타터를 제공합니다. 이 섹션은 Spring Boot에서 메시징을 사용할 때 발생하는 질문에 대한 답변입니다.

9.11.1. 트랜잭션 된 JMS 세션 사용 안함

JMS 브로커가 처리 된 세션을 지원하지 않으면 트랜잭션 지원을 완전히 비활성화해야합니다. 자신 JmsListenerContainerFactory만을 만들면 기본적으로 처리 할 수 ​​없으므로 수행 할 작업이 없습니다. 를 사용하여 DefaultJmsListenerContainerFactoryConfigurerSpring Boot의 기본값을 재사용 하려는 경우 다음과 같이 처리 된 세션을 비활성화 할 수 있습니다.

@Bean
public DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
        ConnectionFactory connectionFactory,
        DefaultJmsListenerContainerFactoryConfigurer configurer) {
    DefaultJmsListenerContainerFactory listenerFactory =
            new DefaultJmsListenerContainerFactory();
    configurer.configure(listenerFactory, connectionFactory);
    listenerFactory.setTransactionManager(null);
    listenerFactory.setSessionTransacted(false);
    return listenerFactory;
}

위의 예제는 기본 팩토리를 대체하며, 애플리케이션이 정의한 다른 팩토리 (있는 경우)에 적용해야합니다.

9.12. 배치 애플리케이션

사람들이 Spring Boot 응용 프로그램 내에서 Spring Batch를 사용할 때 종종 많은 질문이 발생합니다. 이 섹션에서는 이러한 질문을 다룹니다.

9.12.1. 배치 데이터 소스 지정

기본적으로 배치 응용 프로그램에는 DataSource작업 세부 사항을 저장 해야합니다 . 스프링 배치는 DataSource기본적으로 단일 을 기대합니다 . DataSource응용 프로그램의 main 이외의 다른 것을 사용하려면 빈으로 메소드를 주석으로 DataSource선언하십시오 . 그렇게하고 두 개의 데이터 소스를 원하면 다른 하나를 표시해야합니다 . 더 큰 제어권을 얻으려면을 구현하십시오 . 자세한 내용 은 Javadoc 을 참조하십시오.DataSource@Bean@BatchDataSource@PrimaryBatchConfigurer@EnableBatchProcessing

스프링 배치에 대한 자세한 내용은 스프링 배치 프로젝트 페이지를 참조하십시오 .

9.12.2. 시작시 스프링 배치 작업 실행

Spring Batch 자동 구성은 클래스 @EnableBatchProcessing중 하나 에 추가 하여 활성화됩니다 @Configuration.

기본적 으로 시작시 응용 프로그램 컨텍스트에서 모두 실행 됩니다Jobs ( JobLauncherApplicationRunner자세한 내용 참조). spring.batch.job.names쉼표로 구분 된 작업 이름 패턴 목록 을 사용하여 특정 작업을 좁힐 수 있습니다 .

자세한 내용은 BatchAutoConfiguration 및 @EnableBatchProcessing 을 참조하십시오.

9.12.3. 명령 줄에서 실행

Spring Boot는 명령 줄 인수 --를 속성으로 변환 하여 속성에 추가합니다 ( 명령 줄 속성 액세스Environment 참조) . 배치 작업에 인수를 전달하는 데 사용해서는 안됩니다. 명령 행에서 배치 인수를 지정하려면 다음 예제와 같이 일반 형식 (예 :없이 )을 사용하십시오 .--

$ java -jar myapp.jar someParameter = someValue anotherParameter = anotherValue

Environment명령 행에서의 속성을 지정 하면 작업에서 무시됩니다. 다음 명령을 고려하십시오.

$ java -jar myapp.jar --server.port = 7070 someParameter = someValue

이는 일괄 처리 작업에 하나의 인수 만 제공합니다 someParameter=someValue.

9.12.4. 작업 리포지토리 저장

스프링 배치에는 Job리포지토리에 대한 데이터 저장소가 필요 합니다. Spring Boot를 사용하는 경우 실제 데이터베이스를 사용해야합니다. 인 메모리 데이터베이스 일 수 있습니다 ( 작업 저장소 구성 참조) .

9.13. 액추에이터

스프링 부트에는 스프링 부트 액츄에이터가 포함되어 있습니다. 이 섹션은 자주 사용하면서 발생하는 질문에 대한 답변입니다.

9.13.1. Actuator Endpoint의 HTTP 포트 또는 주소 변경

독립형 응용 프로그램에서 Actuator HTTP 포트는 기본적으로 기본 HTTP 포트와 동일합니다. 애플리케이션이 다른 포트에서 청취하도록하려면 외부 특성을 설정하십시오 management.server.port. 완전히 다른 네트워크 주소 (예 : 관리를위한 내부 네트워크가 있고 사용자 응용 프로그램을위한 외부 네트워크가있는 경우) management.server.address를 수신하려면 서버가 바인딩 할 수있는 유효한 IP 주소로 설정할 수도 있습니다 .

자세한 내용 은“제작 준비 기능”섹션 의 ManagementServerProperties소스 코드 및“ 관리 서버 포트 사용자 정의 ”를 참조하십시오.

9.13.2. 'whitelabel'오류 페이지 사용자 정의

Spring Boot는 서버 오류가 발생하면 브라우저 클라이언트에 표시되는 'whitelabel'오류 페이지를 설치합니다 (JSON 및 기타 미디어 유형을 사용하는 머신 클라이언트는 올바른 오류 코드와 함께 적절한 응답을 보게됩니다).

설정 server.error.whitelabel.enabled=false해제 기본 오류 페이지를 전환 할 수 있습니다. 그렇게하면 사용중인 서블릿 컨테이너의 기본값이 복원됩니다. Spring Boot는 여전히 오류보기를 해결하려고 시도하므로 완전히 비활성화하지 않고 자체 오류 페이지를 추가해야합니다.

오류 페이지를 자신의 것으로 재정의하는 것은 사용하는 템플릿 기술에 따라 다릅니다. 예를 들어, Thymeleaf를 사용하는 경우 error.html템플릿을 추가 할 수 있습니다 . FreeMarker를 사용하는 경우 error.ftlh템플릿을 추가 할 수 있습니다 . 일반적으로 View이름으로 해결 error되거나 경로 @Controller를 처리 하는가 필요 합니다 /error. 기본 구성 중 일부를 바꾸지 않는 한,에서을 찾아야 BeanNameViewResolver합니다 ApplicationContext. 따라서 @Bean명명 된 error방법은 간단한 방법입니다. ErrorMvcAutoConfiguration더 많은 옵션을 참조하십시오 .

서블릿 컨테이너에 핸들러를 등록하는 방법에 대한 자세한 내용은 “ 오류 처리 ” 섹션을 참조하십시오 .

9.13.3. 민감한 가치에 대한 위생 처리

엔드 포인트 env와 configprops엔드 포인트가 반환하는 정보는 다소 민감 할 수 있으므로 특정 패턴과 일치하는 키는 기본적으로 삭제됩니다 (즉, 값이로 대체 됨 ******).

사용하는 패턴은 사용하여 사용자 정의 할 수 있습니다 management.endpoint.env.keys-to-sanitize및 management.endpoint.configprops.keys-to-sanitize각각.

스프링 부트는 "password", "secret", "key", "token", "vcap_services", "sun.java.command", "uri", "uris"라는 단어로 끝나는 키에 대해 합리적인 기본값을 사용합니다. , "주소"또는 "주소"가 삭제되었습니다. 또한 키의 credentials일부로 단어를 보유하는 모든 키 는 삭제됩니다 (예 : 정규식으로 구성 .*credentials.*).

살균 할 키가 URI 형식 (예 <scheme>://<username>:<password>@<host>:<port>/:)이면 비밀번호 부분 만 소독됩니다.

9.13.4. 상태 표시기를 마이크로 미터 메트릭에 매핑

스프링 부트 상태 표시기 Status는 전체 시스템 상태를 나타내는 유형을 반환합니다 . 특정 응용 프로그램의 상태 수준을 모니터링하거나 경고하려는 경우 Micrometer를 통해 이러한 상태를 메트릭으로 내보낼 수 있습니다. 기본적으로 상태 코드“UP”,“DOWN”,“OUT_OF_SERVICE”및“UNKNOWN”은 Spring Boot에서 사용됩니다. 이를 내보내려면 이러한 상태를 Micrometer와 함께 사용할 수 있도록 이러한 숫자를 일부 숫자 세트로 변환해야합니다 Gauge.

다음 예제는 이러한 내보내기를 작성하는 한 가지 방법을 보여줍니다.

@Configuration
public class HealthMetricsConfiguration {

    public HealthMetricsConfiguration(MeterRegistry registry, HealthEndpoint healthEndpoint) {
        // This example presumes common tags (such as the app) are applied elsewhere
        Gauge.builder("health", healthEndpoint, this::getStatusCode).strongReference(true).register(registry);
    }

    private int getStatusCode(HealthEndpoint health) {
        Status status = health.health().getStatus();
        if (Status.UP.equals(status)) {
            return 3;
        }
        if (Status.OUT_OF_SERVICE.equals(status)) {
            return 2;
        }
        if (Status.DOWN.equals(status)) {
            return 1;
        }
        return 0;
    }

}

9.14. 보안

이 섹션은 Spring Boot와 함께 스프링 보안을 사용할 때 발생하는 질문을 포함하여 스프링 부트로 작업 할 때의 보안에 대한 질문을 다룹니다.

Spring Security에 대한 자세한 내용은 Spring Security 프로젝트 페이지를 참조하십시오 .

9.14.1. 스프링 부트 보안 구성 끄기

당신이 정의하면 @Configuration와 WebSecurityConfigurerAdapter응용 프로그램에서, 그것은 봄 부트의 기본 웹 애플리케이션 보안 설정을 꺼집니다.

9.14.2. UserDetailsService 변경 및 사용자 계정 추가

당신은을 제공하는 경우 @Bean유형 AuthenticationManager, AuthenticationProvider또는 UserDetailsService, 기본 @Bean에 대한이 InMemoryUserDetailsManager생성되지 않습니다. 즉, 다양한 인증 옵션 과 같은 Spring Security의 모든 기능을 사용할 수 있습니다 .

사용자 계정을 추가하는 가장 쉬운 방법은 고유 한 UserDetailsServiceBean 을 제공하는 것 입니다.

9.14.3. 프록시 서버 뒤에서 실행할 때 HTTPS 사용

모든 기본 엔드 포인트가 HTTPS를 통해서만 사용 가능하도록하는 것은 모든 애플리케이션에서 중요한 일입니다. Tomcat을 서블릿 컨테이너로 사용하는 경우 Spring Boot는 Tomcat이 RemoteIpValve일부 환경 설정을 감지하면 자동으로 Tomcat을 추가 하며 HttpServletRequest보안 여부를보고하는 데 의존 할 수 있어야합니다 (프로세스 를 처리하는 프록시 서버의 다운 스트림조차도) 실제 SSL 종료). 표준 동작은 이름이 일반적인 특정 요청 헤더 ( x-forwarded-for및 x-forwarded-proto) 의 존재 여부에 따라 결정 되므로 대부분의 프런트 엔드 프록시에서 작동해야합니다. application.properties다음 예제와 같이에 몇 가지 항목을 추가하여 밸브를 켤 수 있습니다 .

server.tomcat.remoteip.remote-ip-header=x-forwarded-for
server.tomcat.remoteip.protocol-header=x-forwarded-proto

(이러한 속성 중 하나가 있으면 밸브에 전환됩니다. 또는 콩 RemoteIpValve을 추가하여 추가 할 수 있습니다 TomcatServletWebServerFactory.)

모든 (또는 일부) 요청에 대해 보안 채널을 요구하도록 Spring Security를 ​​구성하려면 WebSecurityConfigurerAdapter다음 HttpSecurity구성 을 추가하는 고유 한 추가를 고려하십시오 .

@Configuration(proxyBeanMethods = false)
public class SslWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // Customize the application security
        http.requiresChannel().anyRequest().requiresSecure();
    }

}

9.15. 핫 스와핑

스프링 부트는 핫 스와핑을 지원합니다. 이 섹션에서는 작동 방식에 대한 질문에 답변합니다.

9.15.1. 정적 컨텐츠 다시로드

핫 리로딩에는 몇 가지 옵션이 있습니다. 권장되는 접근 방식은 spring-boot-devtools빠른 응용 프로그램 재시작 및 LiveReload 지원과 같은 현명한 개발 시간 구성 (템플릿 캐싱 등)과 같은 추가 개발 시간 기능을 제공하므로 사용하는 것입니다. Devtools는 변경 사항에 대한 클래스 경로를 모니터링하여 작동합니다. 즉, 변경 사항을 적용하려면 정적 자원 변경 사항을 "빌드"해야합니다. 기본적으로, 변경 사항을 저장하면 Eclipse에서 자동으로 발생합니다. IntelliJ IDEA에서 프로젝트 만들기 명령은 필요한 빌드를 트리거합니다. 기본 재시작 제외 로 인해 정적 자원을 변경해도 애플리케이션이 재시작되지 않습니다. 그러나 실시간 재 장전을 유발합니다.

또는 IDE에서 (특히 디버깅을 사용하여) 실행하는 것이 개발을 수행하는 좋은 방법입니다 (모든 최신 IDE는 정적 리소스를 다시로드하고 일반적으로 Java 클래스 변경을 핫스왑 할 수 있음).

마지막으로 Maven 및 Gradle 플러그인 은 addResources소스에서 직접 정적 파일을 다시로드하여 명령 줄에서 실행을 지원 하도록 구성 ( 속성 참조) 할 수 있습니다 . 고급 도구를 사용하여 해당 코드를 작성하는 경우 외부 css / js 컴파일러 프로세스와 함께 사용할 수 있습니다.

9.15.2. 컨테이너를 다시 시작하지 않고 템플릿 다시로드

Spring Boot가 지원하는 대부분의 템플릿 기술에는 캐싱을 비활성화하는 구성 옵션이 포함되어 있습니다 (이 문서의 뒷부분에서 설명). spring-boot-devtools모듈 을 사용하는 경우 이러한 특성은 개발시 자동으로 구성 됩니다.

백리향 템플릿

Thymeleaf를 사용하는 경우로 설정 spring.thymeleaf.cache하십시오 false. ThymeleafAutoConfiguration다른 Thymeleaf 사용자 정의 옵션을 참조하십시오 .

FreeMarker 템플릿

FreeMarker를 사용하는 경우로 설정 spring.freemarker.cache하십시오 false. FreeMarkerAutoConfiguration다른 FreeMarker 사용자 정의 옵션을 참조하십시오 .

그루비 템플릿

Groovy 템플릿을 사용하는 경우로 설정 spring.groovy.template.cache하십시오 false. GroovyTemplateAutoConfiguration다른 Groovy 사용자 정의 옵션을 참조하십시오 .

9.15.3. 빠른 응용 프로그램 재시작

이 spring-boot-devtools모듈에는 자동 응용 프로그램 재시작 지원 이 포함되어 있습니다. JRebel 과 같은 기술만큼 빠르지는 않지만 일반적으로 "콜드 스타트 ​​(cold start)"보다 훨씬 빠릅니다. 이 문서의 뒷부분에서 설명하는 좀 더 복잡한 재로드 옵션을 조사하기 전에 시도해보아야 할 것입니다.

자세한 내용은 개발자 도구 섹션을 참조하십시오 .

9.15.4. 컨테이너를 다시 시작하지 않고 Java 클래스 재로드

많은 최신 IDE (Eclipse, IDEA 등)는 바이트 코드의 핫 스와핑을 지원합니다. 결과적으로 클래스 또는 메소드 서명에 영향을 미치지 않는 변경을 수행하면 부작용없이 깨끗하게 다시로드해야합니다.

9.16. 짓다

Spring Boot에는 Maven 및 Gradle 용 빌드 플러그인이 포함되어 있습니다. 이 섹션에서는 이러한 플러그인에 대한 일반적인 질문에 답변합니다.

9.16.1. 빌드 정보 생성

Maven 플러그인과 Gradle 플러그인 모두 프로젝트의 좌표, 이름 및 버전을 포함하는 빌드 정보를 생성 할 수 있습니다. 구성을 통해 추가 속성을 추가하도록 플러그인을 구성 할 수도 있습니다. 이러한 파일이 있으면 Spring Boot는 BuildPropertiesBean을 자동 구성합니다 .

Maven으로 빌드 정보를 생성하려면 build-info다음 예제와 같이 목표에 대한 실행을 추가하십시오 .

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.3.1.RELEASE</version>
            <executions>
                <execution>
                    <goals>
                        <goal>build-info</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

자세한 내용은 Spring Boot Maven Plugin 설명서 를 참조하십시오.

다음 예제는 Gradle과 동일합니다.

springBoot {
    buildInfo()
}

자세한 내용은 Spring Boot Gradle Plugin 설명서 를 참조하십시오.

9.16.2. 힘내 정보 생성

Maven과 Gradle 모두 프로젝트를 빌드 할 때 소스 코드 저장소 git.properties의 상태에 대한 정보가 포함 된 파일을 생성 할 수 git있습니다.

Maven 사용자의 경우 spring-boot-starter-parentPOM에는 git.properties파일 을 생성하기 위해 사전 구성된 플러그인이 포함되어 있습니다. 사용하려면 POM에 다음 선언을 추가하십시오.

<build>
    <plugins>
        <plugin>
            <groupId>pl.project13.maven</groupId>
            <artifactId>git-commit-id-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Gradle 사용자는 gradle-git-properties다음 예제와 같이 플러그인 을 사용하여 동일한 결과를 얻을 수 있습니다 .

plugins {
    id "com.gorylenko.gradle-git-properties" version "2.2.2"
}

커밋 시간 git.properties은 다음 형식과 일치해야합니다 yyyy-MM-dd’T’HH:mm:ssZ.. 위에 나열된 두 플러그인의 기본 형식입니다. 이 형식을 사용하면 시간을 a로 구문 분석 Date하고 JSON으로 직렬화 할 때 Jackson의 날짜 직렬화 구성 설정으로 제어 할 수 있습니다.

9.16.3. 종속성 버전 사용자 정의

spring-boot-dependenciesPOM은 일반적인 의존성의 버전을 관리합니다. Maven 및 Gradle 용 Spring Boot 플러그인을 사용하면 이러한 관리되는 종속성 버전을 빌드 특성을 사용하여 사용자 정의 할 수 있습니다.

각 Spring Boot 릴리즈는 이러한 특정 타사 종속성에 대해 설계되고 테스트되었습니다. 버전을 재정의하면 호환성 문제가 발생할 수 있습니다.

Maven으로 종속성 버전을 재정의하려면 Maven 플러그인 설명서 의이 섹션 을 참조하십시오 .

Gradle에서 종속성 버전을 재정의하려면 Gradle 플러그인 설명서 의이 섹션 을 참조하십시오 .

9.16.4. Maven으로 실행 가능한 JAR 생성

은 spring-boot-maven-plugin실행 "지방"JAR를 만드는 데 사용할 수 있습니다. spring-boot-starter-parentPOM 을 사용하는 경우 플러그인을 선언하면 항아리가 다음과 같이 다시 패키지됩니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

상위 POM을 사용하지 않아도 플러그인을 계속 사용할 수 있습니다. 그러나 <executions>다음과 같이 섹션을 추가해야 합니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.3.1.RELEASE</version>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

자세한 사용법 은 플러그인 설명서 를 참조 하십시오.

9.16.5. 스프링 부트 어플리케이션을 의존성으로 사용

war 파일과 마찬가지로 Spring Boot 응용 프로그램은 종속성으로 사용되지 않습니다. 응용 프로그램에 다른 프로젝트와 공유하려는 클래스가 포함되어 있으면 권장되는 방법은 해당 코드를 별도의 모듈로 옮기는 것입니다. 그런 다음 별도의 모듈은 응용 프로그램과 다른 프로젝트에 따라 달라질 수 있습니다.

위에서 권장 한대로 코드를 재 배열 할 수없는 경우 Spring Boot의 Maven 및 Gradle 플러그인은 종속성으로 사용하기에 적합한 별도의 아티팩트를 생성하도록 구성해야합니다. 실행 파일 아카이브는 실행 파일 jar 형식이의 응용 프로그램 클래스를 패키지화 하므로 종속성으로 사용할 수 없습니다 BOOT-INF/classes. 이는 실행 가능한 jar이 종속성으로 사용될 때 해당 파일을 찾을 수 없음을 의미합니다.

종속성으로 사용할 수있는 하나와 실행 가능한 하나 인 두 개의 아티팩트를 생성하려면 분류자를 지정해야합니다. 이 분류기는 실행 가능한 아카이브의 이름에 적용되며 기본 아카이브는 종속성으로 사용됩니다.

execMaven에서 분류기를 구성하려면 다음 구성을 사용할 수 있습니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <classifier>exec</classifier>
            </configuration>
        </plugin>
    </plugins>
</build>

9.16.6. 실행 가능한 Jar가 실행될 때 특정 라이브러리 추출

실행 가능한 jar의 대부분의 중첩 라이브러리는 실행하기 위해 압축을 풀 필요가 없습니다. 그러나 특정 라이브러리에는 문제가있을 수 있습니다. 예를 들어, JRuby에는 자체 중첩 된 jar 지원이 포함되어 있으며, 이는 jruby-complete.jar자체 파일로 항상 직접 사용할 수 있다고 가정합니다 .

문제가있는 라이브러리를 처리하기 위해 실행 가능한 jar이 처음 실행될 때 특정 중첩 jar이 자동으로 압축 해제되도록 플래그 지정할 수 있습니다. 이러한 중첩 된 jar는 java.io.tmpdir시스템 특성으로 식별 된 임시 디렉토리 아래에 작성됩니다 .

응용 프로그램이 여전히 실행되는 동안 운영 체제가 임시 디렉토리로 압축 해제 된 jar 파일을 삭제하지 않도록 운영 체제가 구성되도록주의해야합니다.

예를 들어 Maven Plugin을 사용하여 JRuby의 압축을 풀도록 플래그를 지정하려면 다음 구성을 추가하십시오.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <requiresUnpack>
                    <dependency>
                        <groupId>org.jruby</groupId>
                        <artifactId>jruby-complete</artifactId>
                    </dependency>
                </requiresUnpack>
            </configuration>
        </plugin>
    </plugins>
</build>

9.16.7. 제외와 함께 실행 불가능한 JAR 작성

실행 파일과 실행 불가능한 jar가 두 개의 개별 빌드 제품으로있는 경우, 실행 가능 버전에는 라이브러리 jar에 필요하지 않은 추가 구성 파일이 있습니다. 예를 들어, application.yml구성 파일이 실행 불가능한 JAR에서 제외 될 수 있습니다.

Maven에서 실행 가능한 jar는 주요 아티팩트 여야하며 다음과 같이 라이브러리에 대해 분류 된 jar을 추가 할 수 있습니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
                <execution>
                    <id>lib</id>
                    <phase>package</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <classifier>lib</classifier>
                        <excludes>
                            <exclude>application.yml</exclude>
                        </excludes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

9.16.8. Maven으로 시작된 Spring Boot 응용 프로그램의 원격 디버그

Maven으로 시작된 Spring Boot 애플리케이션에 원격 디버거를 연결하려면 maven 플러그인 의 jvmArguments특성을 사용할 수 있습니다 .

자세한 내용은 이 예 를 참조하십시오.

9.16.9. spring-boot-antlib를 사용하지 않고 Ant에서 실행 가능한 아카이브 빌드

Ant를 사용하여 빌드하려면 종속성을 가져 와서 컴파일 한 후 jar 또는 war 아카이브를 작성해야합니다. 실행 가능하게하려면 spring-boot-antlib모듈을 사용 하거나 다음 지시 사항을 따르십시오.

1. jar을 빌드하는 경우 응용 프로그램의 클래스 및 자원을 중첩 된 BOOT-INF/classes디렉토리 에 패키지하십시오 . 전쟁을한다면, WEB-INF/classes평소와 같이 애플리케이션의 클래스를 중첩 된 디렉토리 에 패키징하십시오 .
2. BOOT-INF/libjar 또는 WEB-INF/libwar 에 대해 중첩 된 디렉토리에 런타임 종속성을 추가하십시오 . 기억 하지 아카이브의 항목을 압축 할 수 있습니다.
3. jar 또는 war provided의 중첩 BOOT-INF/lib디렉토리에 (임베디드 컨테이너) 종속성을 추가하십시오 WEB-INF/lib-provided. 기억 하지 아카이브의 항목을 압축 할 수 있습니다.
4. spring-boot-loader아카이브의 루트에 클래스를 추가하십시오 ( Main-Class사용 가능하도록).
5. 적절한 시작 프로그램 (예 : JarLauncherjar 파일)을 Main-Class매니페스트 의 속성으로 사용하고 주로 Start-Class속성 을 설정하여 매니페스트 항목으로 필요한 다른 속성을 지정하십시오 .

다음 예제는 Ant를 사용하여 실행 가능 아카이브를 빌드하는 방법을 보여줍니다.

<target name="build" depends="compile">
    <jar destfile="target/${ant.project.name}-${spring-boot.version}.jar" compress="false">
        <mappedresources>
            <fileset dir="target/classes" />
            <globmapper from="*" to="BOOT-INF/classes/*"/>
        </mappedresources>
        <mappedresources>
            <fileset dir="src/main/resources" erroronmissingdir="false"/>
            <globmapper from="*" to="BOOT-INF/classes/*"/>
        </mappedresources>
        <mappedresources>
            <fileset dir="${lib.dir}/runtime" />
            <globmapper from="*" to="BOOT-INF/lib/*"/>
        </mappedresources>
        <zipfileset src="${lib.dir}/loader/spring-boot-loader-jar-${spring-boot.version}.jar" />
        <manifest>
            <attribute name="Main-Class" value="org.springframework.boot.loader.JarLauncher" />
            <attribute name="Start-Class" value="${start-class}" />
        </manifest>
    </jar>
</target>

9.17. 전통적인 배포

스프링 부트는 기존의 배포뿐만 아니라보다 현대적인 형태의 배포를 지원합니다. 이 섹션에서는 기존 배포에 대한 일반적인 질문에 답변합니다.

9.17.1. 배포 가능한 전쟁 파일 만들기

Spring WebFlux는 서블릿 API에 엄격하게 의존하지 않으며 애플리케이션은 기본적으로 임베디드 Reactor Netty 서버에 배치되므로 War 배치는 WebFlux 애플리케이션에 지원되지 않습니다.

배치 가능한 war 파일을 생성하는 첫 번째 단계는 SpringBootServletInitializer서브 클래스 를 제공하고 해당 configure메소드를 대체하는 것입니다. 그렇게하면 Spring Framework의 Servlet 3.0 지원을 사용하고 서블릿 컨테이너에 의해 시작될 때 애플리케이션을 구성 할 수 있습니다. 일반적으로 SpringBootServletInitializer다음 예제와 같이 애플리케이션의 기본 클래스를 확장하여 확장해야합니다 .

@SpringBootApplication
public class Application extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(Application.class);
    }

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

}

다음 단계는 프로젝트가 jar 파일이 아닌 war 파일을 생성하도록 빌드 구성을 업데이트하는 것입니다. Maven 및 spring-boot-starter-parentMaven의 war 플러그인을 구성 하는 Maven을 사용하는 경우 pom.xml다음과 같이 패키징을 war로 변경 하도록 수정 하면됩니다.

<packaging>war</packaging>

Gradle을 사용하는 경우 build.gradle다음과 같이 war 플러그인을 프로젝트에 적용 하도록 수정해야 합니다.

apply plugin: 'war'

프로세스의 마지막 단계는 임베드 된 서블릿 컨테이너가 war 파일이 배치 된 서블릿 컨테이너를 방해하지 않도록하는 것입니다. 이를 위해서는 임베디드 서블릿 컨테이너 종속성이 제공되는 것으로 표시해야합니다.

Maven을 사용하는 경우 다음 예제는 서블릿 컨테이너 (이 경우 Tomcat)가 제공되는 것으로 표시합니다.

<dependencies>
    <!-- … -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
        <scope>provided</scope>
    </dependency>
    <!-- … -->
</dependencies>

Gradle을 사용하는 경우 다음 예제는 서블릿 컨테이너 (이 경우 Tomcat)가 제공되는 것으로 표시합니다.

dependencies {
    // …
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
    // …
}

providedRuntimeGradle의 compileOnly구성 보다 선호됩니다 . 다른 제한 사항 중 compileOnly종속성이 테스트 클래스 경로에 없으므로 웹 기반 통합 테스트가 실패합니다.

Spring Boot 빌드 도구 를 사용하는 경우 , 제공된 서블릿 컨테이너 종속성을 제공된 것으로 표시하면 제공된 종속성이 lib-provided디렉토리에 패키지 된 실행 가능한 war 파일이 생성됩니다 . 즉, 서블릿 컨테이너에 배포 할 수있을뿐 아니라 java -jar명령 줄에서 응용 프로그램을 실행할 수도 있습니다 .

9.17.2. 기존 응용 프로그램을 스프링 부트로 변환

웹이 아닌 응용 프로그램의 경우 기존 Spring 응용 프로그램을 Spring Boot 응용 프로그램으로 쉽게 변환 할 수 있어야합니다. 그렇게하려면을 생성하는 코드를 버리고 or에 대한 ApplicationContext호출로 SpringApplication바꿉니다 SpringApplicationBuilder. Spring MVC 웹 애플리케이션은 일반적으로 먼저 배치 가능한 전쟁 애플리케이션을 작성한 후 나중에 실행 가능한 전쟁 또는 jar로 마이그레이션 할 수 있습니다. 항아리를 전쟁으로 변환하기에 관한 시작 안내서를 참조하십시오 .

SpringBootServletInitializer(예를 들어,라는 클래스에서) 확장 Application하고 스프링 부트 @SpringBootApplication주석을 추가하여 배치 가능한 전쟁을 만들려면 다음 예제에 표시된 것과 유사한 코드를 사용하십시오.

@SpringBootApplication
public class Application extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        // Customize the application or call application.sources(...) to add sources
        // Since our example is itself a @Configuration class (via @SpringBootApplication)
        // we actually don't need to override this method.
        return application;
    }

}

당신이 넣은 sources것은 단지 Spring 이라는 것을 기억하십시오 ApplicationContext. 일반적으로 이미 작동하는 모든 것이 여기에서 작동합니다. 나중에 제거 할 수있는 Bean이있을 수 있으며 Spring Boot가 자체 기본값을 제공하게 할 수도 있지만, 그렇게하기 전에 작동하는 것이 가능해야합니다.

정적 자원에 이동할 수 있습니다 /public(또는 /static또는 /resources또는 /META-INF/resources클래스 패스 루트에). messages.propertiesSpring Boot가 클래스 경로의 루트에서 자동으로 감지하는 경우에도 마찬가지 입니다.

Spring DispatcherServlet및 Spring Security 의 바닐라 사용법은 더 이상 변경하지 않아도됩니다. 애플리케이션에 다른 기능 (예 : 다른 서블릿 또는 필터 사용) Application이있는 web.xml경우 다음과 같이의 요소를 대체 하여 컨텍스트에 일부 구성을 추가해야 합니다.

• @Bean유형의 Servlet또는 ServletRegistrationBean그것이 것처럼 용기에 그 콩을 설치 <servlet/>하고 <servlet-mapping/>에서 web.xml.
• @Bean유형의 A Filter또는 FilterRegistrationBean(a <filter/>및 <filter-mapping/>) 와 유사하게 동작 합니다.
• ApplicationContextXML 파일에서은을 통해 추가 할 수 있습니다 @ImportResource당신에 Application. 또는 주석 구성이 많이 사용되는 간단한 경우를 몇 줄로 @Bean정의 로 다시 만들 수 있습니다 .

war 파일이 작동 하면 다음 예제와 같이에 main메소드를 추가하여 실행 파일을 만들 수 있습니다 Application.

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

애플리케이션을 war 또는 실행 가능한 애플리케이션으로 시작하려는 경우 SpringBootServletInitializer콜백 및 main다음과 유사한 클래스 의 메소드에서 사용 가능한 메소드에서 빌더의 사용자 정의를 공유해야합니다 . @SpringBootApplication public class Application extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return configureApplication(builder); } public static void main(String[] args) { configureApplication(new SpringApplicationBuilder()).run(args); } private static SpringApplicationBuilder configureApplication(SpringApplicationBuilder builder) { return builder.sources(Application.class).bannerMode(Banner.Mode.OFF); } }

응용 프로그램은 둘 이상의 범주에 속할 수 있습니다.

• 아니오 3.0 응용 프로그램을 서블릿 web.xml.
• 와 응용 프로그램 web.xml.
• 컨텍스트 계층이있는 응용 프로그램
• 컨텍스트 계층이없는 응용 프로그램

이들 모두 번역이 가능해야하지만 각각 약간 씩 다른 기술이 필요할 수 있습니다.

Servlet 3.0+ 애플리케이션은 이미 Spring Servlet 3.0+ 이니셜 라이저 지원 클래스를 사용하는 경우 매우 쉽게 변환 될 수 있습니다. 일반적으로 기존의 모든 코드를 WebApplicationInitializer로 이동할 수 있습니다 SpringBootServletInitializer. 기존 애플리케이션에 둘 이상의 애플리케이션이있는 경우 ApplicationContext(예 :를 사용하는 경우 AbstractDispatcherServletInitializer) 모든 컨텍스트 소스를 단일 애플리케이션 으로 결합 할 수 있습니다 SpringApplication. 결합이 작동하지 않고 컨텍스트 계층 구조를 유지 보수해야하는 경우 발생할 수있는 주요 합병증입니다. 예제 는 계층 구조 작성 항목을 참조하십시오 . 웹 특정 기능이 포함 된 기존 상위 컨텍스트는 일반적으로 모든 ServletContextAware구성 요소가 하위 컨텍스트에 있도록 분할되어야합니다.

아직 스프링 애플리케이션이 아닌 애플리케이션은 스프링 부트 애플리케이션으로 변환 가능할 수 있으며 앞에서 언급 한 지침이 도움이 될 수 있습니다. 그러나 아직 문제가 발생할 수 있습니다. 이 경우 에 태그를 사용하여 스택 오버플로에 대해 질문하는spring-boot 것이 좋습니다 .

9.17.3. WebLogic에 WAR 배포

Spring Boot 애플리케이션을 WebLogic에 배치하려면 서블릿 이니셜 라이저가 직접 구현 해야합니다 WebApplicationInitializer(이미 구현 한 기본 클래스에서 확장하더라도).

WebLogic의 일반적인 초기화 프로그램은 다음 예제와 유사해야합니다.

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;
import org.springframework.web.WebApplicationInitializer;

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer implements WebApplicationInitializer {

}

Logback을 사용하는 경우 서버에 사전 설치된 버전이 아닌 패키지 버전을 선호하도록 WebLogic에 지시해야합니다. WEB-INF/weblogic.xml다음 내용이 포함 된 파일을 추가하면 됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
    xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
        https://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd
        http://xmlns.oracle.com/weblogic/weblogic-web-app
        https://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
    <wls:container-descriptor>
        <wls:prefer-application-packages>
            <wls:package-name>org.slf4j</wls:package-name>
        </wls:prefer-application-packages>
    </wls:container-descriptor>
</wls:weblogic-web-app>

9.17.4. 양상추 대신 Jedis 사용

기본적으로 Spring Boot starter ( spring-boot-starter-data-redis)는 Lettuce를 사용합니다 . 그 의존성을 배제하고 대신 Jedis를 포함시켜야합니다 . Spring Boot는 이러한 종속성을 관리하여이 프로세스를 가능한 한 쉽게 만듭니다.

다음 예제는 Maven에서이를 수행하는 방법을 보여줍니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
    <exclusions>
        <exclusion>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
</dependency>

다음 예제는 Gradle에서 수행하는 방법을 보여줍니다.

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-data-redis') {
        exclude group: 'io.lettuce', module: 'lettuce-core'
    }
    implementation 'redis.clients:jedis'
    // ...
}

9.17.5. 통합 테스트를 위해 테스트 컨테이너 사용

Testcontainers의 라이브러리는 부두 노동자 용기 내에서 실행되는 서비스를 관리 할 수있는 방법을 제공합니다. JUnit과 통합되어 테스트 실행 전에 컨테이너를 시작할 수있는 테스트 클래스를 작성할 수 있습니다. 테스트 컨테이너는 MySQL, MongoDB, Cassandra 등과 같은 실제 백엔드 서비스와 통신하는 통합 테스트를 작성하는 데 특히 유용합니다. 테스트 컨테이너는 다음과 같이 스프링 부트 테스트에서 사용할 수 있습니다.

@SpringBootTest
@Testcontainers
class ExampleIntegrationTests {

    @Container
    static Neo4jContainer<?> neo4j = new Neo4jContainer<>();

}

테스트가 실행되기 전에 Neo4j를 실행하는 Docker 컨테이너가 시작됩니다 (Docker가 로컬에서 실행중인 경우). 대부분의 경우 컨테이너 IP 또는 포트와 같이 실행중인 컨테이너의 세부 정보를 사용하여 응용 프로그램을 구성해야합니다.

@DynamicPropertySource스프링 환경에 동적 속성 값을 추가 할 수 있는 정적 메소드를 사용하여 이를 수행 할 수 있습니다 .

@SpringBootTest
@Testcontainers
class ExampleIntegrationTests {

    @Container
    static Neo4jContainer<?> neo4j = new Neo4jContainer<>();

    @DynamicPropertySource
    static void neo4jProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.data.neo4j.uri", neo4j::getBoltUrl);
    }

}

위의 구성을 통해 애플리케이션의 Neo4j 관련 Bean이 Testcontainers 관리 Docker 컨테이너 내에서 실행되는 Neo4j와 통신 할 수 있습니다.

 

Spring Boot Reference Documentation Phillip Webb, Dave Syer, Josh Long, Stéphane Nicoll, Rob Winch, Andy Wilkinson, Marcel Overdijk, Christian Dupuis, Sébastien Deleuze, Michael Simons, Vedran Pavić, Jay Bryant, Madhura Bhave, Eddú Meléndez, Scott Frederick Legal 2.3.1.RELEASE Copyright © 2012-2020 Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

출처 : https://docs.spring.io/spring-boot/docs/2.3.1.RELEASE/reference/htmlsingle/#howto