#Step 02 — Job 과 Step 의 구조

@Autowired private JobBuilderFactory jobBuilderFactory;
@Autowired private StepBuilderFactory stepBuilderFactory;

// ⚠️ Spring Batch 4.3 — 5.1 에서는 컴파일되지 않습니다
package com.example.batch.legacy;

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.configuration.annotation.EnableBatchProcessing;
import org.springframework.batch.core.configuration.annotation.JobBuilderFactory;
import org.springframework.batch.core.configuration.annotation.StepBuilderFactory;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
@EnableBatchProcessing                     // 4.x 에서는 필수였습니다
public class LegacySettlementJobConfig {

    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;

    public LegacySettlementJobConfig(JobBuilderFactory jbf, StepBuilderFactory sbf) {
        this.jobBuilderFactory = jbf;
        this.stepBuilderFactory = sbf;
    }

    @Bean
    public Job settlementJob() {
        return jobBuilderFactory.get("settlementJob")
                .start(settlementStep())
                .build();
    }

    @Bean
    public Step settlementStep() {
        return stepBuilderFactory.get("settlementStep")
                .tasklet((contribution, chunkContext) -> {
                    System.out.println("정산 중...");
                    return RepeatStatus.FINISHED;
                })
                .build();                  // 트랜잭션 매니저를 안 넘깁니다
        }
}

// Spring Batch 4.3 의 JobBuilderFactory (요약)
public class JobBuilderFactory {
    private final JobRepository jobRepository;
    public JobBuilder get(String name) {
        return new JobBuilder(name).repository(this.jobRepository);
    }
}

// ✅ Spring Batch 5.1
package com.example.batch.step02;

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

@Configuration
public class SettlementJobConfig {          // @EnableBatchProcessing 없음

    @Bean
    public Job settlementJob(JobRepository jobRepository, Step settlementStep) {
        return new JobBuilder("settlementJob", jobRepository)
                .start(settlementStep)
                .build();
    }

    @Bean
    public Step settlementStep(JobRepository jobRepository,
                               PlatformTransactionManager txManager) {
        return new StepBuilder("settlementStep", jobRepository)
                .tasklet((contribution, chunkContext) -> {
                    System.out.println("정산 중...");
                    return RepeatStatus.FINISHED;
                }, txManager)               // 트랜잭션 매니저를 명시
                .build();
    }
}

// Spring Batch 5.1 의 JobBuilder 생성자
public class JobBuilder extends JobBuilderHelper<JobBuilder> {

    public JobBuilder(String name, JobRepository jobRepository) {
        super(name, jobRepository);       // JobRepository 가 필수 인자
    }

    @Deprecated(since = "5.0")
    public JobBuilder(String name) { ... }   // 5.1 에서도 남아 있지만 쓰지 마세요
}

// ⚠️ 컴파일도 되고 IDE 도 조용하지만
return new JobBuilder("settlementJob")
        .start(settlementStep)
        .build();

// Spring Batch 5.1 의 StepBuilder
public class StepBuilder extends StepBuilderHelper<StepBuilder> {

    public StepBuilder(String name, JobRepository jobRepository) { ... }

    public TaskletStepBuilder tasklet(Tasklet tasklet, PlatformTransactionManager txManager) { ... }

    public <I, O> SimpleStepBuilder<I, O> chunk(int chunkSize, PlatformTransactionManager txManager) { ... }

    public <I, O> SimpleStepBuilder<I, O> chunk(CompletionPolicy policy, PlatformTransactionManager txManager) { ... }
}

@Bean
public Step whichTxStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
    return new StepBuilder("whichTxStep", jobRepository)
            .tasklet((contribution, chunkContext) -> {
                System.out.println(">>> txManager = " + txManager.getClass().getName());
                return RepeatStatus.FINISHED;
            }, txManager)
            .build();
}

@AutoConfiguration(after = { HibernateJpaAutoConfiguration.class, TransactionAutoConfiguration.class })
@ConditionalOnClass({ JobLauncher.class, DataSource.class, DatabasePopulator.class })
@ConditionalOnBean({ DataSource.class, PlatformTransactionManager.class })
@ConditionalOnMissingBean(value = DefaultBatchConfiguration.class,
                          annotation = EnableBatchProcessing.class)     // ★
@EnableConfigurationProperties(BatchProperties.class)
public class BatchAutoConfiguration { ... }

@Configuration
@EnableBatchProcessing            // ⚠️ 이 한 줄만 추가
public class TrapConfig { }

@EnableBatchProcessing(
        dataSourceRef = "batchDataSource",
        transactionManagerRef = "batchTxManager",
        tablePrefix = "BATCH_",
        isolationLevelForCreate = "ISOLATION_SERIALIZABLE",
        taskExecutorRef = "batchTaskExecutor"
)

@Bean
public Job pipelineJob(JobRepository jobRepository,
                       Step extractStep, Step transformStep, Step loadStep) {
    return new JobBuilder("pipelineJob", jobRepository)
            .start(extractStep)
            .next(transformStep)
            .next(loadStep)
            .build();
}

// ⚠️ 위험한 코드 — 컴파일도 되고 한 번은 잘 돕니다
@Configuration
public class StatefulStepConfig {

    private int counter = 0;                 // 설정 클래스의 필드

    @Bean
    public Step statefulStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
        return new StepBuilder("statefulStep", jobRepository)
                .tasklet((contribution, chunkContext) -> {
                    counter++;
                    System.out.println(">>> counter = " + counter);
                    return RepeatStatus.FINISHED;
                }, txManager)
                .build();
    }
}

package com.example.batch.step02;

/*
 * ============================================================================
 * Step 02 — Job 과 Step 의 구조  :  본문 예제 모음
 * ============================================================================
 *
 * 실행
 *   ./gradlew bootRun --args='--spring.batch.job.name=settlementJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=whichTxJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=pipelineJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=statefulJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=statefulFixedJob'
 *
 * ⚠️ 이 파일에서 가장 주의할 것
 *    [2-6] TrapConfig 의 주석을 풀면 @EnableBatchProcessing 이 켜져
 *    BatchAutoConfiguration 이 통째로 물러나고 "모든 Job 이 부팅 시 실행되지 않습니다".
 *    함정을 재현한 뒤에는 반드시 다시 주석 처리하세요.
 * ============================================================================
 */

import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.item.ExecutionContext;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.batch.support.transaction.ResourcelessTransactionManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

public final class Practice {

    private Practice() {
    }

    // =========================================================================
    // [2-2] Spring Batch 4.3 의 방식 — 5.1 에서는 컴파일되지 않습니다
    // -------------------------------------------------------------------------
    // 주석을 풀면 다음 에러가 납니다. 그것을 확인하는 것도 실습입니다.
    //
    //   error: cannot find symbol
    //     symbol:   class JobBuilderFactory
    //     symbol:   class StepBuilderFactory
    //
    // 확인했으면 다시 주석으로 되돌리세요.
    // =========================================================================
    /*
    @Configuration
    @EnableBatchProcessing                                   // (1) 4.x 에서는 필수
    public static class LegacySettlementJobConfig {

        private final JobBuilderFactory jobBuilderFactory;   // (2) 팩토리 필드
        private final StepBuilderFactory stepBuilderFactory; // (3) 팩토리 필드

        public LegacySettlementJobConfig(JobBuilderFactory jbf, StepBuilderFactory sbf) {
            this.jobBuilderFactory = jbf;
            this.stepBuilderFactory = sbf;
        }

        @Bean
        public Job settlementJob() {
            return jobBuilderFactory.get("settlementJob")    // (4) get(name)
                    .start(settlementStep())                 // (5) 메서드 직접 호출
                    .build();
        }

        @Bean
        public Step settlementStep() {
            return stepBuilderFactory.get("settlementStep")  // (6) get(name)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println("정산 중...");
                        return RepeatStatus.FINISHED;
                    })                                       // (7) 트랜잭션 매니저 없음
                    .build();
        }
    }
    */

    // =========================================================================
    // [2-3] 같은 설정의 Spring Batch 5.1 판  —  위 블록과 나란히 놓고 비교하세요
    // -------------------------------------------------------------------------
    //   (1) @EnableBatchProcessing 삭제            → Boot 자동설정이 대신
    //   (2)(3) 팩토리 필드 삭제                     → JobRepository 를 파라미터로
    //   (4)(6) get(name) → new XxxBuilder(name, jobRepository)
    //   (5) 메서드 직접 호출 → Step 을 파라미터로 주입
    //   (7) .tasklet(t) → .tasklet(t, txManager)
    // =========================================================================
    @Configuration
    public static class SettlementJobConfig {

        @Bean
        public Job settlementJob(JobRepository jobRepository, Step settlementStep) {
            return new JobBuilder("settlementJob", jobRepository)
                    .start(settlementStep)
                    .build();
        }

        @Bean
        public Step settlementStep(JobRepository jobRepository,
                                   PlatformTransactionManager txManager) {
            return new StepBuilder("settlementStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println("정산 중...");
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [2-4] JobRepository 없이 만들면? — 시끄럽게 실패합니다
    // -------------------------------------------------------------------------
    // 주석을 풀고 실행하면 빈 초기화 시점에 다음이 납니다.
    //
    //   java.lang.IllegalArgumentException: JobRepository must be set
    //     at org.springframework.batch.core.job.AbstractJob.afterPropertiesSet(...)
    //
    // Job 이 "잘못 도는" 것이 아니라 "아예 못 뜨는" 것이므로 좋은 실패입니다.
    // =========================================================================
    /*
    @Configuration
    public static class NoRepositoryJobConfig {
        @Bean
        public Job brokenJob(Step settlementStep) {
            return new JobBuilder("brokenJob")      // deprecated 생성자 — JobRepository 없음
                    .start(settlementStep)
                    .build();
        }
    }
    */

    // =========================================================================
    // [2-5] 주입된 PlatformTransactionManager 가 무엇인지 눈으로 확인
    // -------------------------------------------------------------------------
    // 이 프로젝트는 spring-boot-starter-data-jpa 를 포함하므로 결과는
    //   >>> txManager = org.springframework.orm.jpa.JpaTransactionManager
    // 입니다. DataSourceTransactionManager 가 나오면 JPA 스타터가 빠진 것입니다.
    //
    // 왜 확인해야 하는가: DataSource 가 둘 이상인 프로젝트에서 Step 의 트랜잭션과
    // ItemWriter 가 쓰는 커넥션이 어긋나면, 청크가 롤백돼도 쓰기가 남습니다.
    // 예외는 정상적으로 나므로 로그만 보면 롤백된 줄 압니다.
    // =========================================================================
    @Configuration
    public static class WhichTxJobConfig {

        @Bean
        public Job whichTxJob(JobRepository jobRepository, Step whichTxStep) {
            return new JobBuilder("whichTxJob", jobRepository).start(whichTxStep).build();
        }

        @Bean
        public Step whichTxStep(JobRepository jobRepository,
                                PlatformTransactionManager txManager) {
            return new StepBuilder("whichTxStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> txManager = " + txManager.getClass().getName());
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [2-5'] DB 를 건드리지 않는 Step — ResourcelessTransactionManager
    // -------------------------------------------------------------------------
    // 알림 발송, 파일 이동 같은 Tasklet 에 진짜 DB 트랜잭션을 열 이유가 없습니다.
    // 단, JobRepository 의 메타데이터 갱신은 여전히 진짜 DB 트랜잭션으로 나갑니다.
    // (JobRepository 는 자기 트랜잭션 매니저를 별도로 갖고 있습니다)
    // =========================================================================
    @Configuration
    public static class ResourcelessJobConfig {

        @Bean
        public Job notifyJob(JobRepository jobRepository, Step notifyStep) {
            return new JobBuilder("notifyJob", jobRepository).start(notifyStep).build();
        }

        @Bean
        public Step notifyStep(JobRepository jobRepository) {
            return new StepBuilder("notifyStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> 정산 완료 알림 발송 (DB 미사용)");
                        return RepeatStatus.FINISHED;
                    }, new ResourcelessTransactionManager())
                    .build();
        }
    }

    // =========================================================================
    // [2-6] ★ 함정 재현용 ★  @EnableBatchProcessing
    // -------------------------------------------------------------------------
    // 주석을 풀면:
    //   - BatchAutoConfiguration 이 통째로 물러납니다.
    //   - JobLauncherApplicationRunner 가 없어져 "모든 Job 이 실행되지 않습니다".
    //   - BATCH_* 테이블이 없는 상태라면 BadSqlGrammarException 으로 시끄럽게 죽고,
    //     테이블이 이미 있다면 아무 에러 없이 종료코드 0 으로 조용히 끝납니다. ← 최악
    //
    // 확인 방법:
    //   ./gradlew bootRun --args='--debug' 2>&1 | grep -A2 'BatchAutoConfiguration'
    //   → "Did not match: @ConditionalOnMissingBean ... found beans of annotation
    //      type EnableBatchProcessing 'trapConfig'"
    //
    // ⚠️ 재현이 끝나면 반드시 다시 주석 처리하세요.
    // =========================================================================
    /*
    @Configuration
    @EnableBatchProcessing
    public static class TrapConfig {
    }
    */

    // =========================================================================
    // [2-7] Step 세 개를 .next() 로 잇기
    // -------------------------------------------------------------------------
    // 로그에서 "Executing step:" 이 3번 나와야 정상입니다.
    // BATCH_JOB_EXECUTION 은 1행, BATCH_STEP_EXECUTION 은 3행입니다.
    //
    // ⚠️ transformStep 이 ExitStatus("WARN") 을 반환해도 loadStep 은 실행됩니다.
    //    .next() 는 ExitStatus 가 아니라 BatchStatus 를 보기 때문입니다.
    //    ExitStatus 로 분기하려면 Step 10 의 .on("WARN").to(...) 가 필요합니다.
    // =========================================================================
    @Configuration
    public static class PipelineJobConfig {

        @Bean
        public Job pipelineJob(JobRepository jobRepository,
                               Step extractStep, Step transformStep, Step loadStep) {
            return new JobBuilder("pipelineJob", jobRepository)
                    .start(extractStep)
                    .next(transformStep)
                    .next(loadStep)
                    .build();
        }

        @Bean
        public Step extractStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("extractStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> extract : orders 에서 COMPLETED 70000건 확인");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }

        @Bean
        public Step transformStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("transformStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> transform : 수수료율 적용 규칙 로드");
                        // ExitStatus 를 바꿔도 .next() 흐름은 그대로 진행됩니다.
                        contribution.setExitStatus(new ExitStatus("WARN", "환율 테이블이 어제 것입니다"));
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }

        @Bean
        public Step loadStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("loadStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> load : settlement 적재 준비 완료");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // [2-8] ⚠️ 잘못된 방식 — 설정 클래스 필드에 상태를 둔다
    // -------------------------------------------------------------------------
    // Step 빈은 싱글턴입니다. 람다가 캡처한 것은 이 설정 클래스 인스턴스이고,
    // 그것은 JVM 이 살아 있는 동안 하나뿐입니다.
    //
    // 로컬에서는 bootRun 한 번 = JVM 한 번이라 counter 가 항상 1 입니다. 절대 재현 안 됩니다.
    // 운영에서 Quartz 로 같은 JVM 안에서 하루 24번 돌리면 counter 가 24까지 올라갑니다.
    // =========================================================================
    @Configuration
    public static class StatefulStepConfig {

        private int counter = 0;

        @Bean
        public Job statefulJob(JobRepository jobRepository, Step statefulStep) {
            return new JobBuilder("statefulJob", jobRepository).start(statefulStep).build();
        }

        @Bean
        public Step statefulStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("statefulStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        counter++;
                        System.out.println(">>> [BAD] counter = " + counter);
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // [2-8'] ✅ 올바른 방식 — ExecutionContext 에 둔다
    // -------------------------------------------------------------------------
    // 실행마다 0 부터 시작하고, 값이 BATCH_STEP_EXECUTION_CONTEXT 에 저장되어
    // 재시작 시 이어집니다.
    //
    //   SELECT STEP_EXECUTION_ID, SHORT_CONTEXT FROM BATCH_STEP_EXECUTION_CONTEXT;
    //   → {"@class":"java.util.HashMap","counter":1, ...}
    // =========================================================================
    @Configuration
    public static class StatefulFixedConfig {

        @Bean
        public Job statefulFixedJob(JobRepository jobRepository, Step statefulFixedStep) {
            return new JobBuilder("statefulFixedJob", jobRepository)
                    .start(statefulFixedStep)
                    .build();
        }

        @Bean
        public Step statefulFixedStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("statefulFixedStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        ExecutionContext ctx = chunkContext.getStepContext()
                                .getStepExecution().getExecutionContext();
                        long counter = ctx.getLong("counter", 0L) + 1;
                        ctx.putLong("counter", counter);
                        System.out.println(">>> [GOOD] counter = " + counter);
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // [2-10] 마이그레이션 확인용 명령/SQL 모음
    // =========================================================================
    public static final String MIGRATION_CHECKS = """
            # 1. 삭제된 팩토리가 남아 있는가 (컴파일러가 잡아 주지만 먼저 확인)
            grep -rn 'JobBuilderFactory\\|StepBuilderFactory' src/

            # 2. ★ 컴파일러가 못 잡는 항목 — 반드시 grep 할 것
            grep -rn 'EnableBatchProcessing' src/

            # 3. jakarta 전환 누락
            grep -rn 'javax\\.persistence\\|javax\\.annotation' src/

            # 4. 자동설정이 살아 있는지 확인
            ./gradlew bootRun --args='--debug' 2>&1 | grep -A2 'BatchAutoConfiguration'

            -- 5. 5.x 스키마인지 확인 (PARAMETER_NAME/TYPE/VALUE 3컬럼이어야 함)
            DESC BATCH_JOB_EXECUTION_PARAMS;

            -- 6. 4.x 잔재 컬럼이 남아 있는지
            SHOW COLUMNS FROM BATCH_JOB_EXECUTION LIKE 'JOB_CONFIGURATION_LOCATION';

            -- 7. 4.x → 5.x 파라미터 테이블 마이그레이션 DDL
            ALTER TABLE BATCH_JOB_EXECUTION_PARAMS
              DROP COLUMN TYPE_CD,
              DROP COLUMN DATE_VAL,
              DROP COLUMN LONG_VAL,
              DROP COLUMN DOUBLE_VAL,
              CHANGE COLUMN KEY_NAME   PARAMETER_NAME  VARCHAR(100)  NOT NULL,
              CHANGE COLUMN STRING_VAL PARAMETER_VALUE VARCHAR(2500),
              ADD COLUMN PARAMETER_TYPE VARCHAR(100) NOT NULL AFTER PARAMETER_NAME;

            ALTER TABLE BATCH_JOB_EXECUTION DROP COLUMN JOB_CONFIGURATION_LOCATION;

            -- 8. Step 실행 이력 확인
            SELECT STEP_EXECUTION_ID, STEP_NAME, STATUS, COMMIT_COUNT, EXIT_CODE
            FROM BATCH_STEP_EXECUTION
            WHERE JOB_EXECUTION_ID = (SELECT MAX(JOB_EXECUTION_ID) FROM BATCH_JOB_EXECUTION)
            ORDER BY STEP_EXECUTION_ID;
            """;
}

package com.example.batch.step02;

/*
 * ============================================================================
 * Step 02 — 연습문제 (6문제)
 * ============================================================================
 *
 * 규칙
 *   - "// 여기에 작성:" 자리를 채웁니다.
 *   - 예측을 요구하는 문제는 반드시 먼저 적고 나서 실행하세요.
 *     예측이 틀린 지점이 이 스텝의 학습 포인트입니다.
 *   - 정답은 Solution.java.
 * ============================================================================
 */

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

public final class Exercise {

    private Exercise() {
    }

    // =========================================================================
    // 문제 1. 4.x 설정 클래스를 5.1 로 마이그레이션하기  ★ 이 스텝의 본체
    // -------------------------------------------------------------------------
    // 아래 주석 블록이 Spring Batch 4.3 기준 원본입니다.
    // 그 아래 Ex1Config 를 5.1 방식으로 완성하세요.
    //
    // 치환해야 할 곳이 다섯 군데입니다. 그중 "컴파일러가 안 잡아 주는 것"이 하나 있습니다.
    // 어느 것인지 찾아서 아래에 적으세요.
    //
    //   컴파일러가 안 잡아 주는 항목:
    //   →
    //   그것을 놓치면 나타나는 증상:
    //   →
    //
    // ── 원본 (4.3) ──────────────────────────────────────────────────────────
    //
    // @Configuration
    // @EnableBatchProcessing
    // public class DailyCloseJobConfig {
    //
    //     private final JobBuilderFactory jobBuilderFactory;
    //     private final StepBuilderFactory stepBuilderFactory;
    //
    //     public DailyCloseJobConfig(JobBuilderFactory jbf, StepBuilderFactory sbf) {
    //         this.jobBuilderFactory = jbf;
    //         this.stepBuilderFactory = sbf;
    //     }
    //
    //     @Bean
    //     public Job dailyCloseJob() {
    //         return jobBuilderFactory.get("dailyCloseJob")
    //                 .start(closeStep())
    //                 .next(archiveStep())
    //                 .build();
    //     }
    //
    //     @Bean
    //     public Step closeStep() {
    //         return stepBuilderFactory.get("closeStep")
    //                 .tasklet((contribution, chunkContext) -> {
    //                     System.out.println("일마감 처리");
    //                     return RepeatStatus.FINISHED;
    //                 })
    //                 .build();
    //     }
    //
    //     @Bean
    //     public Step archiveStep() {
    //         return stepBuilderFactory.get("archiveStep")
    //                 .tasklet((contribution, chunkContext) -> {
    //                     System.out.println("아카이브");
    //                     return RepeatStatus.FINISHED;
    //                 })
    //                 .build();
    //     }
    // }
    // ────────────────────────────────────────────────────────────────────────
    // =========================================================================
    @Configuration
    public static class Ex1Config {

        // 여기에 작성: dailyCloseJob (closeStep → archiveStep)

        // 여기에 작성: closeStep

        // 여기에 작성: archiveStep
    }

    // =========================================================================
    // 문제 2. JobRepository 없는 JobBuilder
    // -------------------------------------------------------------------------
    //   new JobBuilder("ex2Job")          ← deprecated 생성자, JobRepository 없음
    //           .start(someStep)
    //           .build();
    //
    // ★ 실행하기 전에 예측을 적으세요.
    //
    //   (a) 컴파일은 되는가?                                  →
    //   (b) 예외가 난다면 클래스명은?                          →
    //   (c) 예외 메시지는?                                     →
    //   (d) 발생 시점은 "빈 초기화" 인가 "Job 실행" 인가?       →
    //   (e) 이 실패는 시끄러운 실패인가 조용한 실패인가?        →
    //
    // 확인한 뒤 아래에 실제 결과를 적으세요.
    //   실제:
    //   →
    // =========================================================================

    // =========================================================================
    // 문제 3. @EnableBatchProcessing 을 붙이면 사라지는 빈 3개
    // -------------------------------------------------------------------------
    // Practice.java 의 [2-6] TrapConfig 주석을 풀고 아래를 실행해 보세요.
    //
    //   ./gradlew bootRun --args='--debug' 2>&1 | grep -A2 'BatchAutoConfiguration'
    //
    // 사라지는 빈과 그 증상을 매칭하세요.
    //
    //   (1) 빈: ____________________________________
    //       증상: ______________________________________________________
    //
    //   (2) 빈: ____________________________________
    //       증상: ______________________________________________________
    //
    //   (3) 설정 바인딩: ___________________________
    //       증상: ______________________________________________________
    //
    //   세 증상 중 "조용한" 것은 몇 번인가?  →
    //   그것을 탐지하려면 로그에서 무슨 문자열을 찾아야 하나?  →
    //
    // ⚠️ 확인이 끝나면 TrapConfig 를 반드시 다시 주석 처리하세요.
    // =========================================================================

    // =========================================================================
    // 문제 4. ExitStatus 를 바꿔도 .next() 는 진행되는가
    // -------------------------------------------------------------------------
    // 요구사항
    //   - Job 이름: ex4Job
    //   - Step 3개: ex4StepA → ex4StepB → ex4StepC
    //   - ex4StepB 는 contribution.setExitStatus(new ExitStatus("WARN", "..."))
    //     를 호출한 뒤 정상 종료한다.
    //
    // ★ 실행 전 예측
    //   ex4StepC 는 실행되는가?  →
    //   그 이유는?               →
    //
    // 실행 후 확인
    //   SELECT STEP_NAME, STATUS, EXIT_CODE FROM BATCH_STEP_EXECUTION
    //   WHERE JOB_EXECUTION_ID = (SELECT MAX(JOB_EXECUTION_ID) FROM BATCH_JOB_EXECUTION);
    //
    //   실제 결과와, .next() 가 무엇을 보고 판단하는지 한 문장으로 정리하세요.
    //   →
    // =========================================================================
    @Configuration
    public static class Ex4Config {

        @Bean
        public Job ex4Job(JobRepository jobRepository,
                          Step ex4StepA, Step ex4StepB, Step ex4StepC) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex4StepA(JobRepository jobRepository, PlatformTransactionManager tx) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex4StepB(JobRepository jobRepository, PlatformTransactionManager tx) {
            // 여기에 작성: ExitStatus 를 "WARN" 으로 설정한 뒤 정상 종료
            return null;
        }

        @Bean
        public Step ex4StepC(JobRepository jobRepository, PlatformTransactionManager tx) {
            // 여기에 작성:
            return null;
        }
    }

    // =========================================================================
    // 문제 5. 상태를 가진 Step 을 ExecutionContext 기반으로 고치기
    // -------------------------------------------------------------------------
    // 아래는 "이 Step 이 몇 번째로 처리한 파일인지" 를 세는 코드입니다.
    // 지금은 설정 클래스 필드를 쓰고 있어 같은 JVM 에서 여러 번 실행하면 값이 누적됩니다.
    //
    // ExecutionContext 를 쓰도록 고치세요.
    //   - JobExecution 의 컨텍스트가 아니라 StepExecution 의 컨텍스트를 쓸 것
    //   - 왜 StepExecution 쪽인지 이유를 주석으로 적을 것
    //   - 실행 후 BATCH_STEP_EXECUTION_CONTEXT.SHORT_CONTEXT 에 어떤 JSON 이
    //     저장되는지 확인해 아래에 붙여 넣을 것
    //
    //   저장된 JSON:
    //   →
    // =========================================================================
    @Configuration
    public static class Ex5Config {

        private int fileCount = 0;   // ⚠️ 이 필드를 없애야 합니다

        @Bean
        public Job ex5Job(JobRepository jobRepository, Step ex5Step) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex5Step(JobRepository jobRepository, PlatformTransactionManager tx) {
            // 여기에 작성: fileCount 를 ExecutionContext 로 옮긴 버전
            return null;
        }
    }

    // =========================================================================
    // 문제 6. ResourcelessTransactionManager 와 메타데이터
    // -------------------------------------------------------------------------
    // 요구사항
    //   - Job 이름: ex6Job / Step 이름: ex6Step
    //   - Step 의 트랜잭션 매니저로 new ResourcelessTransactionManager() 를 쓴다
    //   - Tasklet 은 주입된 txManager 의 클래스명을 출력한다
    //
    // ★ 실행 전 예측
    //   (a) BATCH_STEP_EXECUTION 에 행이 남는가?     →
    //   (b) 남는다면/안 남는다면 그 이유는?            →
    //
    // 실행 후 확인
    //   SELECT STEP_NAME, STATUS, COMMIT_COUNT FROM BATCH_STEP_EXECUTION
    //   WHERE STEP_NAME = 'ex6Step';
    //
    //   실제 결과:
    //   →
    //   Step 의 트랜잭션 매니저와 JobRepository 의 트랜잭션 매니저의 관계를 한 문장으로:
    //   →
    // =========================================================================
    @Configuration
    public static class Ex6Config {

        @Bean
        public Job ex6Job(JobRepository jobRepository, Step ex6Step) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex6Step(JobRepository jobRepository) {
            // 여기에 작성:
            return null;
        }
    }
}

package com.example.batch.step02;

/*
 * ============================================================================
 * Step 02 — 연습문제 정답 및 해설
 * ============================================================================
 * Exercise.java 를 먼저 풀어 본 뒤에 보세요.
 * ============================================================================
 */

import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.item.ExecutionContext;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.batch.support.transaction.ResourcelessTransactionManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

public final class Solution {

    private Solution() {
    }

    // =========================================================================
    // 정답 1. 4.3 → 5.1 마이그레이션
    // =========================================================================
    //
    // 치환한 다섯 군데
    //
    //   ① @EnableBatchProcessing            → 삭제          ★ 컴파일러가 못 잡음
    //   ② JobBuilderFactory  필드/생성자     → 삭제, 파라미터 주입으로
    //   ③ StepBuilderFactory 필드/생성자     → 삭제, 파라미터 주입으로
    //   ④ xxxBuilderFactory.get(name)       → new XxxBuilder(name, jobRepository)
    //   ⑤ .tasklet(t)                       → .tasklet(t, txManager)
    //
    // 그리고 부수적으로 closeStep() / archiveStep() 메서드 직접 호출을
    // @Bean 메서드 파라미터 주입으로 바꿨습니다.
    //
    // ★ 컴파일러가 못 잡는 항목은 ① 하나뿐입니다.
    //
    //   ②③④⑤ 는 타입이 없어졌거나 시그니처가 바뀌었으므로 빌드가 깨집니다.
    //   빌드가 깨지는 것은 좋은 실패입니다. 고칠 수밖에 없으니까요.
    //
    //   그런데 ① 은 애너테이션이 여전히 존재하고, 붙여도 컴파일이 됩니다.
    //   심지어 애플리케이션도 정상 기동합니다.
    //   결과는 "BatchAutoConfiguration 이 물러나 JobLauncherApplicationRunner 가
    //   등록되지 않고, 부팅 시 Job 이 하나도 실행되지 않는" 것입니다.
    //   에러 없이, 로그도 깨끗하게, 종료 코드 0 으로 끝납니다.
    //
    //   즉 마이그레이션 PR 은 "빌드가 통과했으니 됐다" 로 끝나고,
    //   배포된 뒤 첫 배치 시간에 아무 일도 일어나지 않습니다.
    //   그리고 아무도 모릅니다. 알람이 안 오니까요.
    //
    //   → 마이그레이션 PR 에서 가장 먼저 실행할 명령:
    //        grep -rn 'EnableBatchProcessing' src/
    //     결과가 비어 있어야 합니다.
    //
    @Configuration
    public static class Sol1Config {

        @Bean
        public Job dailyCloseJob(JobRepository jobRepository, Step closeStep, Step archiveStep) {
            return new JobBuilder("dailyCloseJob", jobRepository)
                    .start(closeStep)
                    .next(archiveStep)
                    .build();
        }

        @Bean
        public Step closeStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("closeStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println("일마감 처리");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }

        @Bean
        public Step archiveStep(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("archiveStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println("아카이브");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // 정답 2. JobRepository 없는 JobBuilder
    // =========================================================================
    //
    //   (a) 컴파일은 됩니다. new JobBuilder(String) 생성자는 5.1 에도 남아 있습니다
    //       (@Deprecated(since = "5.0") 로 표시만 되어 있습니다).
    //
    //   (b) java.lang.IllegalArgumentException
    //
    //   (c) "JobRepository must be set"
    //
    //   (d) 빈 초기화 시점입니다.
    //       스택트레이스의 맨 위가 이렇습니다.
    //         at org.springframework.util.Assert.state(Assert.java:76)
    //         at org.springframework.batch.core.job.AbstractJob.afterPropertiesSet(AbstractJob.java:141)
    //       AbstractJob 은 InitializingBean 을 구현하고 있어서,
    //       컨테이너가 빈을 만들 때 afterPropertiesSet() 이 호출되며 거기서 검사합니다.
    //       Job 을 실행하기도 전에 애플리케이션 기동이 실패합니다.
    //
    //   (e) 시끄러운 실패입니다. 그리고 이것이 옳습니다.
    //
    // 왜 좋은 설계인가:
    //   JobRepository 가 없는 Job 은 메타데이터를 남길 수 없습니다.
    //   즉 "어디까지 처리했는지 기억하지 못하는 배치" 입니다.
    //   그런 Job 이 조용히 돌아서 절반쯤 처리하고 죽는다면 복구할 방법이 없습니다.
    //   그러느니 애플리케이션이 아예 안 뜨는 게 낫습니다.
    //
    //   deprecated 생성자를 남겨 둔 것도 이 검사 덕에 안전합니다.
    //   "잘못 쓸 수 있게 열어 두되, 잘못 쓰면 즉시 크게 실패하게 한다" 는 패턴입니다.

    // =========================================================================
    // 정답 3. @EnableBatchProcessing 을 붙이면 사라지는 것
    // =========================================================================
    //
    //   (1) 빈: JobLauncherApplicationRunner
    //       증상: 부팅 시 Job 이 자동 실행되지 않는다.
    //             에러 없음, 로그 없음, 종료 코드 0.   ← ★ 조용한 증상
    //
    //   (2) 빈: BatchDataSourceScriptDatabaseInitializer
    //       증상: spring.batch.jdbc.initialize-schema 가 무시되어 BATCH_* 테이블이
    //             생성되지 않는다. 테이블이 없는 상태라면
    //             BadSqlGrammarException: Table 'batchdb.BATCH_JOB_INSTANCE' doesn't exist
    //             로 시끄럽게 죽는다.  ← 시끄러움, 그나마 다행
    //
    //   (3) 설정 바인딩: BatchProperties (spring.batch.*)
    //       증상: table-prefix, job.name 등 application.yml 설정이 반영되지 않는다.
    //             table-prefix 를 커스텀으로 쓰고 있었다면 기본값 BATCH_ 로 되돌아가
    //             "테이블이 없다" 또는 "빈 메타데이터를 보고 처음부터 다시 실행" 이 된다.
    //
    //   조용한 것은 (1) 입니다.
    //
    //   탐지 문자열: "launched with the following parameters"
    //     이 줄이 로그에 없으면 Job 이 한 번도 실행되지 않은 것입니다.
    //     운영에서는 이 문자열의 부재를 알림 조건으로 거는 것이 좋습니다.
    //     (배치 로그는 "무엇이 있었는가" 보다 "무엇이 없었는가" 가 더 중요할 때가 많습니다)
    //
    //   진단 명령:
    //     ./gradlew bootRun --args='--debug' 2>&1 | grep -A2 'BatchAutoConfiguration'
    //
    //     BatchAutoConfiguration:
    //        Did not match:
    //           - @ConditionalOnMissingBean (... annotations: ...EnableBatchProcessing)
    //             found beans of annotation type EnableBatchProcessing 'trapConfig'
    //
    //     원인 빈 이름까지 알려 줍니다.

    // =========================================================================
    // 정답 4. ExitStatus 를 바꿔도 ex4StepC 는 실행됩니다
    // =========================================================================
    //
    // 결과
    //   +--------------+-----------+-----------+
    //   | STEP_NAME    | STATUS    | EXIT_CODE |
    //   +--------------+-----------+-----------+
    //   | ex4StepA     | COMPLETED | COMPLETED |
    //   | ex4StepB     | COMPLETED | WARN      |   ← ExitStatus 만 WARN
    //   | ex4StepC     | COMPLETED | COMPLETED |   ← 실행됨
    //   +--------------+-----------+-----------+
    //
    // 왜인가:
    //   SimpleJob 은 각 Step 실행 후 stepExecution.getStatus() — 즉 BatchStatus 를 봅니다.
    //   COMPLETED 이면 다음 Step 으로 진행하고, 아니면 Job 을 중단합니다.
    //   ExitStatus 는 아예 보지 않습니다.
    //
    //     .next() 가 보는 것 = BatchStatus (enum, 프레임워크가 정함)
    //     .on(...)  가 보는 것 = ExitStatus  (문자열, 개발자가 정할 수 있음)
    //
    // 흔한 오해와 그 결과:
    //   "ExitStatus 를 SKIPPED 로 바꿨으니 뒤 Step 은 안 돌겠지" 라고 믿고
    //   휴일 처리 로직을 만들면, 휴일에도 정산이 그대로 돕니다.
    //   에러는 안 납니다. 로그도 COMPLETED 입니다.
    //   ExitStatus 로 흐름을 바꾸려면 반드시 FlowBuilder 를 써야 합니다(Step 10).
    //
    //     new JobBuilder("ex4Job", jobRepository)
    //             .start(ex4StepA)
    //             .next(ex4StepB)
    //             .on("WARN").end()            // ← 이렇게 해야 흐름이 바뀝니다
    //             .from(ex4StepB).on("*").to(ex4StepC)
    //             .end()
    //             .build();
    //
    @Configuration
    public static class Sol4Config {

        @Bean
        public Job ex4Job(JobRepository jobRepository,
                          Step ex4StepA, Step ex4StepB, Step ex4StepC) {
            return new JobBuilder("ex4Job", jobRepository)
                    .start(ex4StepA)
                    .next(ex4StepB)
                    .next(ex4StepC)
                    .build();
        }

        @Bean
        public Step ex4StepA(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("ex4StepA", jobRepository)
                    .tasklet((c, cc) -> {
                        System.out.println(">>> A");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }

        @Bean
        public Step ex4StepB(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("ex4StepB", jobRepository)
                    .tasklet((c, cc) -> {
                        System.out.println(">>> B (ExitStatus=WARN)");
                        c.setExitStatus(new ExitStatus("WARN", "환율 테이블이 어제 것입니다"));
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }

        @Bean
        public Step ex4StepC(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("ex4StepC", jobRepository)
                    .tasklet((c, cc) -> {
                        System.out.println(">>> C (실행됩니다)");
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // 정답 5. 상태를 ExecutionContext 로 옮기기
    // =========================================================================
    //
    // 왜 StepExecution 의 컨텍스트인가 (JobExecution 이 아니라):
    //
    //   - 세는 대상이 "이 Step 이 처리한 파일 수" 이므로 수명이 Step 과 같아야 합니다.
    //   - 재시작 시 Spring Batch 는 실패한 StepExecution 의 컨텍스트를 복원해
    //     같은 Step 의 새 실행에 넘겨 줍니다. 즉 "이어서 세기" 가 공짜로 됩니다.
    //   - JobExecution 컨텍스트에 두면 Job 안의 다른 Step 도 볼 수 있어
    //     의도치 않은 공유가 생깁니다. 공유가 필요할 때만 그쪽을 쓰세요(Step 09).
    //
    // 저장되는 JSON (BATCH_STEP_EXECUTION_CONTEXT.SHORT_CONTEXT):
    //
    //   {"@class":"java.util.HashMap","fileCount":1,
    //    "batch.taskletType":"com.example.batch.step02.Solution$Sol5Config$$Lambda/0x...",
    //    "batch.stepType":"org.springframework.batch.core.step.tasklet.TaskletStep"}
    //
    //   batch.* 두 개는 프레임워크가 넣은 것이고, fileCount 가 우리 값입니다.
    //   @class 가 붙는 이유는 4.3 부터 기본 직렬화가 Jackson JSON 이기 때문입니다.
    //
    // ⚠️ 여기서 putLong 을 쓴 이유:
    //   ExecutionContext 는 put(String, Object) 도 받습니다. 아무 객체나 넣을 수 있습니다.
    //   넣는 순간에는 에러가 안 납니다. 커밋 시 직렬화하다가, 또는 재시작 시
    //   역직렬화하다가 터집니다. 즉 "정상 실행 때는 멀쩡하고 장애 복구 때만 터지는"
    //   최악의 타이밍입니다. putLong / putString / putDouble 처럼 타입이 명시된
    //   메서드만 쓰는 습관이 이 사고를 막습니다.
    //
    @Configuration
    public static class Sol5Config {

        @Bean
        public Job ex5Job(JobRepository jobRepository, Step ex5Step) {
            return new JobBuilder("ex5Job", jobRepository).start(ex5Step).build();
        }

        @Bean
        public Step ex5Step(JobRepository jobRepository, PlatformTransactionManager tx) {
            return new StepBuilder("ex5Step", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        ExecutionContext ctx = chunkContext.getStepContext()
                                .getStepExecution().getExecutionContext();
                        long fileCount = ctx.getLong("fileCount", 0L) + 1;
                        ctx.putLong("fileCount", fileCount);
                        System.out.println(">>> fileCount = " + fileCount);
                        return RepeatStatus.FINISHED;
                    }, tx)
                    .build();
        }
    }

    // =========================================================================
    // 정답 6. ResourcelessTransactionManager 를 써도 메타데이터는 정상 저장됩니다
    // =========================================================================
    //
    //   (a) BATCH_STEP_EXECUTION 에 행이 정상적으로 남습니다.
    //
    //   +-----------+-----------+--------------+
    //   | STEP_NAME | STATUS    | COMMIT_COUNT |
    //   +-----------+-----------+--------------+
    //   | ex6Step   | COMPLETED |            1 |
    //   +-----------+-----------+--------------+
    //
    //   (b) 이유: 트랜잭션 매니저가 두 군데에 따로 있기 때문입니다.
    //
    //       ┌─────────────────────────────────────────────────────────┐
    //       │ Step 의 트랜잭션 매니저                                   │
    //       │  = .tasklet(t, txManager) 로 넘긴 것                     │
    //       │  = "업무 데이터" 쓰기의 트랜잭션 경계                      │
    //       │  → ResourcelessTransactionManager 로 두면 실제 DB 트랜잭션│
    //       │    을 열지 않습니다 (커넥션을 낭비하지 않습니다)           │
    //       └─────────────────────────────────────────────────────────┘
    //       ┌─────────────────────────────────────────────────────────┐
    //       │ JobRepository 의 트랜잭션 매니저                          │
    //       │  = Boot 자동설정이 DataSource 로 만들어 준 것             │
    //       │  = "메타데이터" 갱신의 트랜잭션 경계                       │
    //       │  → Step 설정과 무관하게 진짜 DB 트랜잭션으로 나갑니다      │
    //       └─────────────────────────────────────────────────────────┘
    //
    //       이 분리를 모르면 "리소스리스로 바꿨으니 메타데이터도 안 남겠지" 라는
    //       잘못된 걱정을 하게 됩니다. 남습니다.
    //
    // ⚠️ 반대로 정말 위험한 조합은 이것입니다.
    //
    //       Step 의 tx        → DataSource A (업무 DB)
    //       JobRepository 의 tx → DataSource B (메타데이터 DB)
    //
    //    이러면 청크 커밋과 메타데이터 갱신이 서로 다른 트랜잭션입니다.
    //    청크는 커밋됐는데 메타데이터 갱신 직전에 프로세스가 죽으면,
    //    "처리는 됐지만 처리했다는 기록은 없는" 상태가 됩니다.
    //    재시작하면 같은 데이터를 한 번 더 처리합니다. 중복 정산입니다.
    //    에러는 나지 않습니다. 그저 숫자가 두 배일 뿐입니다.
    //
    //    프로젝트 셋업(P-1)이 "한 트랜잭션으로 묶고 싶다면 같은 DataSource 여야 한다"
    //    고 적은 이유가 이것이고, Step 11 에서 이 트레이드오프를 다시 다룹니다.
    //
    @Configuration
    public static class Sol6Config {

        @Bean
        public Job ex6Job(JobRepository jobRepository, Step ex6Step) {
            return new JobBuilder("ex6Job", jobRepository).start(ex6Step).build();
        }

        @Bean
        public Step ex6Step(JobRepository jobRepository) {
            PlatformTransactionManager resourceless = new ResourcelessTransactionManager();
            return new StepBuilder("ex6Step", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> step tx = " + resourceless.getClass().getName());
                        System.out.println(">>> DB 를 건드리지 않는 Step 입니다");
                        return RepeatStatus.FINISHED;
                    }, resourceless)
                    .build();
        }
    }
}