2. Spring Batch 5.0 has the following major themes:

자바 17 필요
주요(Major) 의존성 업그레이드
배치 인프라 구성 업데이트
배치 테스트 구성 업데이트
잡 파라미터 핸들링 업데이트
실행 컨텍스트 직렬화(serialization) 업데이트
SystemCommandTasklet 업데이트
새로운 기능(features)
모델경량화(Pruning)

2.1. Java 17 Requirement

스프링 배치는 자바 버전 및 서드 파티 의존성에 관련하여 스프링 프레임워크 기준을 따른다. 스프링 배치 5에서 스프링 프레임워크 버전은 자바 17이 필요한 스프링 프레임워크6으로 업그레이드됐다.

2.2. Major dependencies upgrade

스프링 배치가 사용하는 서드 파티 라이브러리의 지원 버전과의 통합을 위해, 스프링 배치 5는 전반적으로 의존성을 다음 버전으로 업데이트한다:

스프링 프레임워크 6
스프링 인테그레이션 6
스프링 데이터 3
스프링 AMQP 3
스프링 for 아파치 카프카 3
마이크로미터 1.10

이 릴리스는 다음 마이그레이션을 했다:

자카르타 EE 9
하이버네이트 6

2.3. Batch Infrastructure Configuration Updates

스프링 배치 5에는 다음과 같은 인프라 구성 업데이트가 포함된다:

데이터 소스 및 트랜잭션 매니저 요구 사항 업데이트
트랜잭션 매니저 빈(Bean) 노출
EnableBatchProcessing의 새로운 어노테이션 애트리뷰트
인프라스트럭처 빈에 대한 새 구성 클래스
잡익스플로러(JobExplorer) 및 잡오퍼레이터(JobOperator)의 트랜잭션 지원

2.3.1. Data Source and Transaction manager Requirement Updates

과거이력으로, 스프링 배치는 메모리 내 잡 리포지터리(job repository)와 함께 작동하도록 맵(Map) 기반 잡 리포지터리 및 잡 익스플로러(job explorer) 구현체을 제공했다. 이러한 구현체는 버전 4에서 더 이상 사용되지 않으며 버전 5에서 완전히 제거됐다. H2, HSQL 등과 같은 임베디드 데이터베이스와 함께 JDBC 기반 구현체로 교체하여 사용하는 것을 권장한다.

이 릴리스에서, @EnableBatchProcessing 어노테이션(annotation)은 데이터소스(DataSource) 및 플랫폼트랜젝션매니저(PlatformTransactionManager) 빈이 필요하며, 애플리케이션 컨텍스트에서 정의할 JDBC 기반 잡리포지터리(JobRepository)를 구성한다. 데이터소스(DataSource) 빈은 임베디드 데이터베이스를 참조하여 인 메모리 잡 리포지터리와 함께 작동할 수 있다.

2.3.2. Transaction Manager Bean Exposure

버전 4.3까지, @EnableBatchProcessing 어노테이션은 애플리케이션 컨텍스트에서 트랜잭션 매니저 빈을 노출했다. 이것은 보통 편리하지만 트랜잭션 매니저의 무조건적 노출은 커스텀 트랜잭션 매니저를 방해할 수 있다. 이 릴리스에서, @EnableBatchProcessing은 더 이상 애플리케이션 컨텍스트에서 트랜잭션 매니저 빈을 노출하지 않는다.

2.3.3. New annotation attributes in EnableBatchProcessing

이 릴리스에서, @EnableBatchProcessing 어노테이션은 배치 인프라스트럭처 빈을 구성하는 데 사용해야 하는 구성 요소와 파라미터를 지정하는 새 애트리뷰트을 제공한다. 예를 들어, 다음과 같이 잡 리포지터리에서 스프링 배치가 구성해야 하는 데이터 소스 및 트랜잭션 매니저를 지정할 수 있다:

  @Configuration
  @EnableBatchProcessing(dataSourceRef = "batchDataSource", transactionManagerRef = "batchTransactionManager")
  public class MyJobConfiguration {
    @Bean
    public Job job(JobRepository jobRepository) {
        return new JobBuilder("myJob", jobRepository)
        //필요에 따라 작업 흐름 정의
        .build();
    } 
  }

이 예제에서, batchDataSource 및 batchTransactionManager는 애플리케이션 컨텍스트의 빈을 참조하며 잡 리포지터리 및 잡 익스플로러를 구성하는 데 사용된다. 이 릴리스에서 제거된 커스텀 배치컨피규어러(BatchConfigurer)를 더 이상 정의할 필요가 없다.

2.3.4. New configuration class for infrastructure beans

이 릴리스에서, 디폴트배치컨피규레이션(DefaultBatchConfiguration)이라는 새 구성 클래스를 인프라스트럭처 빈 구성에 @EnableBatchProcessing을 대신해 사용할 수 있다. 이 클래스는 필요에 따라 커스텀할 수 있는 기본 구성으로 인프라스트럭처 빈을 제공한다. 다음 스니펫(snippet)은 이 클래스의 일반적인 사용법을 보여준다:

  @Configuration
  class MyJobConfiguration extends DefaultBatchConfiguration {
    @Bean
    public Job job(JobRepository jobRepository) {
        return new JobBuilder("myJob", jobRepository)
        //필요에 따라 작업 흐름 정의
        .build();
    } 
  }

이 예제에서, 잡(Job) 빈 정의에 주입된 잡리포지터리(JobRepository) 빈은 디폴트배치컨피규레이션(DefaultBatchConfiguration) 클래스에서 정의된다. 해당 getter를 오버라이드(override)하여 맞춤 파라미터를 지정할 수 있다. 예를 들어, 다음 예는 잡 리포지터리 및 잡 익스플로러에서 사용되는 기본 문자 인코딩을 오버라이드하는 방법을 보여준다:

  @Configuration
  class MyJobConfiguration extends DefaultBatchConfiguration {
    @Bean
    public Job job(JobRepository jobRepository) {
        return new JobBuilder("job", jobRepository)
        //필요에 따라 작업 흐름 정의
        .build();
    }
    
    @Override
    protected Charset getCharset() {
        return StandardCharsets.ISO_8859_1;
    }
  }

2.4. Job parameters handling updates

2.4.1. Support for any type as a job parameter

이 버전은 v4에서와 같이 미리 정의된 4가지 타입(long, double, string, date)뿐만 아니라 모든 타입을 잡 파라미터로 사용하기 위한 지원이 추가됐다. 이 변경 사항은 데이터베이스에서 잡 파라미터가 유지되는 방식에 영향을 미친다. 더 이상 미리 정의된 각 타입에 대한 4개의 개별 컬럼은 없다. DDL 변경에 대한 BATCH_JOB_EXECUTION_PARAMS의 컬럼 변경을 확인하자. 이제 파라미터 타입의 정규화된 이름과 파라미터 값이 문자열(String)로 유지된다. 문자열 리터럴은 표준 스프링 컨버전 서비스(standard Spring conversion service)를 사용하여 파라미터 타입으로 변환된다. 표준 컨버전 서비스는 사용자의 특정 타입을 문자열 리터럴로 변환하거나 문자열 리터럴에서 특정 타입으로 변환하는 데 필요한 컨버터(converter)로 보강할 수 있다.

2.4.2. Default job parameter conversion

v4에서 잡 파라미터의 기본 표기법은 다음과 같이 지정됐다:

  [+|-]parameterName(parameterType)=value

여기서 parameterType은 [string,long,double,date] 중 하나이다. 이 표기법은 제한, 제약이 있고, 환경 변수와 잘 작동하지 않으며 스프링 부트와 친숙하지 않다.

v5에서는 잡 파라미터를 지정하는 두 가지 방법이 있다:

`기본 표기법`

기본 표기법은 이제 다음과 같이 지정된다:

  parameterName=parameterValue,parameterType,identificationFlag

여기서 parameterType은 파라미터 타입의 이름이다. 스프링 배치는 이 표기법을 지원하기 위해 디폴트잡파라미터컨버터(DefaultJobParametersConverter)를 제공한다.

`확장 표기법`

기본 표기법은 대부분의 상황에 적합하지만, 예를 들어 값에 쉼표가 포함된 것이 불편할 수 있다. 이 경우 스프링 부트의 Json 애플리케이션 프로퍼티에서 영감을 얻은 확장 표기법을 사용할 수 있으며 다음과 같이 지정한다:

  parameterName='{"value": "parameterValue", "type":"parameterType", "identifying":"booleanValue"}'

여기서 parameterType은 파라미터 타입의 이름이다. 스프링 배치는 이 표기법을 지원하기 위해 Json잡파라미터컨버터(JsonJobParametersConverter)를 제공한다.

2.5. Execution context serialization updates

v5부터, Base64로/에서 컨텍스트를 직렬화(serialize)/역직렬화하도록(deserialize) 디폴트익스큐션컨텍스트시리얼라이저(DefaultExecutionContextSerializer)가 업데이트되었다. 또한, @EnableBatchProcessing 또는 디폴트배치컨피규레이션(DefaultBatchConfiguration)으로 구성된 기본 익스큐션컨텍스트시리얼라이저(ExecutionContextSerializer)가 잭슨익스큐션컨텍스트스트링시리얼라이저(JacksonExecutionContextStringSerializer)에서 디폴트익스큐션컨텍스트시리얼라이저(DefaultExecutionContextSerializer)로 변경됐다. 잭슨(Jackson)에 대한 의존성이 선택 사항이 되었다. 잭슨익스큐션컨텍스트스트링시리얼라이저(JacksonExecutionContextStringSerializer)를 사용하기 위해서는 클래스패스에 jackson-core를 추가해야 한다.

2.6. SystemCommandTasklet updates

SystemCommandTasklet은 이 릴리스에서 재검토됐고 다음과 같이 변경했다:

tasklet 익스큐션에서 커맨드 익스큐션(command execution)을 분리하기 위해 커맨드러너(CommandRunner)라는 새로운 전략 인터페이스가 도입되었다. 기본 구현체는 java.lang.Runtime#exec API를 사용하여 시스템 명령을 실행하는 Jvm커맨드러너(JvmCommandRunner)이다. 이 인터페이스는 다른 API를 사용하여 시스템 명령을 실행하도록 구현할 수 있다.
명령을 실행하는 메서드는 이제 명령과 해당 아규먼트(arguments)를 나타내는 문자열(String) 배열을 허용한다. 더 이상 명령을 토큰화하거나 전 처리(pre-processing)를 수행할 필요가 없다. 이 변경으로 API가 더 직관적이고 오류가 덜 발생한다.

2.7. Batch Testing Configuration Updates

스프링 배치 5에는 다음과 같은 테스트 구성 업데이트가 포함되어 있다:

테스트 유틸리티에서 autowiring 제거
JUnit Jupiter로 마이그레이션

2.7.1. Removal of autowiring from test utilities

버전 4.3까지, 잡런처테스트유틸(JobLauncherTestUtils) 및 잡리포지터리테스트유틸(JobRepositoryTestUtils)는 테스트 중인 잡과 테스트 인프라 설정을 용이하게 하기 위한 테스트 데이터 소스를 autowire하는 데 사용됐다. 이는 대부분의 상황에 편리했지만, 여러 잡 또는 여러 데이터 소스가 정의된 테스트 컨텍스트에 대해 몇 가지 문제를 일으키는 것으로 나타났다. 이 릴리스에서, 이러한 유틸리티를 수동으로 또는 @SpringBatchTest 어노테이션을 통해 가져오는 동안 문제를 방지하기 위해 이러한 의존성의 autowiring을 제거하는 몇 가지 변경 사항을 도입했다.

2.7.2. Migration to JUnit Jupiter

이 릴리스에서, 스프링 배치의 전체 테스트 케이스가 JUnit 5로 마이그레이션되었다. 이는 최종 사용자에게 직접적인 영향을 미치지 않지만, 배치 팀과 커뮤니티 기여자가 차세대 JUnit을 사용하여 더 나은 테스트를 작성하는 데 도움이 된다.

2.8. New features

2.9. Transaction support in JobExplorer and JobOperator

이 릴리스는 잡익스플로러팩토리빈(JobExplorerFactoryBean)을 통해 생성된 잡익스플로러(JobExplorer)에서 트랜잭션 지원을 도입한다. 이제 트랜잭션 애트리뷰트를 커스텀 가능할 뿐만 아니라 배치 메타데이터를 쿼리할 때 읽기 전용 트랜잭션을 구동하는 데 사용할 트랜잭션 매니저를 지정할 수 있다.

동일한 트랜잭션 지원이 잡오퍼레이션팩토리빈(JobOperatorFactoryBean)이라는 새 팩토리 빈을 통해 잡오퍼레이터(JobOperator)에 추가됐다.

2.9.1. Automatic registration of a JobOperator with EnableBatchProcessing

버전 4부터, EnableBatchProcessing 어노테이션은 스프링 배치 잡을 시작하는 데 필요한 모든 기본 인프라스트럭처 빈을 제공했다. 그러나, 잡 실행 중지, 재시작 및 실행을 포기하는 주요 진입점인, 잡 오퍼레이터(job operator) 빈을 등록하지 않았다.

이러한 유틸리티는 잡 실행만큼 자주 사용되지는 않지만, 애플리케이션 컨텍스트에서 잡 오퍼레이터를 자동으로 추가하면 최종 사용자가 이러한 빈을 수동으로 구성할 필요가 없다.

2.9.2. Improved Java records support

청크(chunk) 지향 스텝(step)의 아이템으로 자바 레코드(Record)에 대한 지원은 v4.3에서 처음 도입됐지만, v4에는 자바 8이 기본이었기 때문에 지원이 제한됐다. 초기 지원은 자바 16의 java.lang.Record API에 접근하지 않고, 자바 레코드를 생성하고 데이터로 채우는 리플렉션 트릭(reflection tricks)을 기반으로 했다.

이제 v5에는 자바 17이 기본이므로, 프레임워크의 다른 부분에서 레코드(Record) API를 활용하여 스프링 배치에 레코드 지원을 개선했다. 예를 들어, 플랫파일아이템리더빌더(FlatFileItemReaderBuilder)는 이제 아이템 타입이 레코드인지 일반 클래스인지 감지하고 그에 따라 해당 필드셋매퍼(FieldSetMapper) 구현체를 구성(예: 레코드의 경우 레코드필드셋매퍼(RecordFieldSetMapper) 및 일반 클래스의 경우 빈래퍼필드셋매퍼(BeanWrapperFieldSetMapper))할 수 있다. 여기서의 목표는 필요한 필드셋매퍼(FieldSetMapper) 타입의 구성을 사용자에게 투명하게 만드는 것이다.

2.9.3. Batch tracing with Micrometer

마이크로미터 1.10으로 업그레이드하면, 이제 배치 메트릭 외에 배치 트레이싱(tracing)을 사용할 수 있다. 스프링 배치는 각 잡에 대한 span과 잡 내의 각 스텝(step)에 대한 span을 생성한다. 예를 들어 집킨(Zipkin)과 같은 대시보드에서 트레이싱(tracing) 메타 데이터를 수집해 볼 수 있다.

또한, 이번 릴리스에서는 현재 활성 스텝(step)에서, 제공된 잡런처(JobLauncher)를 통한 잡 시작 횟수와 같은 새로운 지표를 소개한다.

2.9.4. Java 8 features updates

예를 들어, 자바 8+의 기능으로 코드 베이스를 개선하기 위해 이 주요 릴리스의 기회를 잡았다:

인터페이스에서 기본 메서드를 사용하고 “support” 클래스를 더 이상 사용하지 않음(이슈 3924 참고)
퍼블릭(public) API에서 적절한 위치에 @FunctionalInterface 추가 (이슈 4107 참고)
날짜 및 시간 API의 유형을 잡 파라미터로 사용하도록 지원한다. (이슈 1035 참고)

2.9.5. Support for SAP HANA a job repository

이 릴리스에서는 잡 리포지터리에 대한 추가 지원 데이터베이스로 SAP HANA 지원을 소개한다.

2.9.6. Full support for MariaDB as a separate product

v4.3까지 스프링 배치는 마리아DB를 MySQL로 간주하여 지원했다. 이 릴리스에서 마리아DB는 자체 DDL 스크립트 및 데이터필드맥스벨류인크리먼터(DataFieldMaxValueIncrementer)가 있는 독립 제품으로 취급한다.

2.9.7. New Maven Bill Of Materials for Spring Batch modules

이 기능은 여러 번 요청되었으며 마침내 v5에서 제공된다. 이제 새로 추가된 Maven BOM을 사용하여 일관된 버전으로 스프링 배치 모듈을 가져올 수 있다.

2.9.8. UTF-8 by default

파일 기반 아이템 리더(readers)와 라이터(writers) 사이의 일관성 없는 기본 인코딩, 익스큐션 컨텍스트에서 멀티바이트 문자를 처리할 때 직렬화/역직렬화 문제 등과 같이, 프레임워크의 여러 영역에서 수년 동안 문자 인코딩과 관련된 몇 가지 문제가 보고됐다.

JEP 400과 동일한 정신으로 UTF-8 선언문(manifesto)을 따르는, 이 릴리스는 프레임워크의 모든 영역에서 기본 인코딩을 UTF-8로 업데이트하고 필요에 따라 이 기본값을 구성할 수 있도록 했다.

2.9.9. Full GraalVM native support

그랄VM(GraalVM) 네이티브 이미지 컴파일러를 사용하여 스프링 배치 애플리케이션을 네이티브 실행 파일로 컴파일하기 위한 지원을 제공하려는 노력은 v4.2에서 시작되었으며 v4.3에서 실험적으로 제공되었다. 이 릴리스에서는 GraalVM을 사용하여 스프링 배치 애플리케이션을 기본적으로 컴파일하는 데 필요한 런타임 힌트를 제공하여 기본 지원이 크게 개선되었으며 이제 베타 버전으로 간주한다.

2.9.10. Execution context Meta-data improvement

런타임 정보(예: 스텝 타입, 재시작 플래그 등)와 관련하여 익스큐션 컨텍스트에서 스프링 배치가 이미 유지하는 것 외에도, 이 릴리스에서는 컨텍스트를 직렬화하는 데 사용된 스프링 배치 버전인 실행 컨텍스트에 중요한 세부 정보를 추가한다.

이것은 사소해 보이지만, 익스큐션 컨텍스트 직렬화 및 역직렬화와 관련하여 업그레이드 문제를 디버깅할 때 엄청난 부가가치가 있다.

2.9.11. Improved documentation

이 릴리스에서, 스프링 Asciidoctor 벡엔드를 사용하도록 문서가 업데이트되었다. 이 백엔드는 포트폴리오의 모든 프로젝트가 동일한 문서 스타일을 따르도록 한다. 다른 프로젝트와 일관성을 위해 이 릴리스에서, 이 백엔드를 사용하도록 스프링 배치의 레퍼런스 문서가 업데이트되었다.

2.10. Pruning

스프링 배치 5는 다음을 포함하여 더 이상 필요하지 않은 여러 항목을 제거한다:

API 지원 중단 및 제거
SQLFire 지원 종료
GemFire 지원 종료
JSR-352 구현 제거

2.10.1. API 지원 중단 및 제거(API deprecation and removal)

이 주요 릴리스에서는 이전 버전에서 더 이상 사용하지 않는 모든 API가 제거되었다. 또한, 일부 API는 v5.0에서 더 이상 사용되지 않으며 v5.2에서 제거될 예정이다. 마지막으로, 일부 API는 실질적인 이유로 사용 중단 없이 이동되거나 제거되었다. 이러한 변경 사항에 대한 자세한 내용은 마이그레이션 가이드를 참고하자.

2.10.2. SQLFire 지원 종료(SQLFire Support Removal)

SqlFire는 2014년 11월 1일부로 제품단종(EOL)을 발표했다. 작업 리포지터리로서 SQLFire 지원은 버전 v4.3에서 더 이상 사용되지 않으며 버전 v5.0에서 제거되었다.

2.10.3. GemFire 지원 종료(GemFire support removal)

Apache Geode, 스프링 데이터의 지원 중단 결정에 따라, 스프링 배치에서 Geode 지원이 제거되었다. 코드는 커뮤니티의 노력에 따라 spring-batch-extensions리포지터리로 이동되었다.

2.10.4. JSR-352 구현 제거(JSR-352 Implementation Removal)

관심 부족으로 인해, 이 릴리스에서는 JSR-352의 구현이 중단되었다.