자사 제품을 SpringBatch을 커스텀 하여 제공하는 방향으로 가고 있는데

기존 자사 모듈 코드들을 SpringBatch에서 사용 할 수 있도록 몇가지 작업들(Mock 처리 및 ThreadLocal로 값 세팅)이 필요했습니다.

그래서 처음에는 간단한 Tasklet을 가지고 테스트 하며 어디에 적용할지 생각했을때

AOP를 적용하는 방법을 생각하다 Tasklet이 Bean 대상이 아닐경우 동작 안하는 케이스가 생길수 있기 때문에

다른 방향을 생각하다 TransactionChunkListener의 존재를 알고 해당 부분으로 선후 작업 처리를 할 수 있도록 했습니다.

(그냥 트랜잭션 앞뒤에 해주면 되겠다고 생각했었습니다.)

최근 ETL에서 다른것들을 테스트 할 일이 있어 테스트하다보니 ItemReader의 open()시에 자사 모듈이 정상적으로 동작하지 않는것을 확인하고 SpringBatch 코드를 열어보게 되었습니다.

결국 open을 호출하는 코드는 org.springframework.batch.core.step.AbstractStep에 :205에서 호출하고 있었고

초기화하는 ChunkListener의 경우 :208에 doExecute 안쪽에서 수행되고있었습니다.

어떻게 처리를 할까 고민을 하다 

open을 수행하는 :205 를 보니 :204 beforeStep에서 stepExecutionListener를 호출해주고 있었습니다.

결국에는 stepExecutionListener에서 자사 모듈을 위한 초기화 작업과 폐기 처리들을 하고

TransactionChunkListener는 실제 트랜잭션 처리만 할 수 있도록 변경했습니다.

(open을 트랜잭션 밖에서 하고 있다는게 의외긴 했습니다..)

역시 틈틈히 관련 코드들을 봐야 제대로된 코드를 작성할 수 있을것 같습니다.

properties에 따라서 Injection해야하는 Bean을 변경해야 했습니다

물론 Profile을 통해서 Bean 등록을 바꾼다던지 여러 방법이 있겠지만

프레임워크 엔진에는 구현체가 여러개가 있고

사용자가 선택해서 쓸수 있도록 제공하기 위해 Profile을 통해서는 애매하여

@Qualifier에 변수를 적용하여 처리를 시도해봤습니다.

@Autowired

@Qualifier("${user.handler:simpleHandler}")

user.handler에 bean명이 설정되어있으면 설정된 bean값을 쓰고 아니면 기본값인 simpleHandler Bean을 주입하길 원했지만 동작하지 않았습니다

(@ComponentScan이나 @ImportResource 도 다 변수가 적용됬는데 @Qualifier는 동작을 안했습니다..;;)

그래서 어떻게 처리를 할까 고민 하다

기본으로 돌아가서 ApplicationContext.getBean()을 활용하는 방법으로 일단 적용해두었습니다.

@Value("${user.handler:simpleHandler}")
String handlerBeanName;

@PostConstruct
private void postConstruct() {
	this.handler = applicationContext.getBean(handlerBeanName);
}

추후 @Qualifier는 어떤 단계에서 어떤방식으로 처리하는지 봐야할것 같습니다.

설정이 다 jar 내에 있으면 좋겠지만

외부에서 설정 받는 경우를 고려해야하고 엔진에서 어떤 데이터소스를 사용하게 될지 명시를 해줘야하기 때문에

기존 설정인 "spring.datasource.hikari.xxx"설정은 감추고 "engine.ds.xxx" 형식으로 지원을 처리하고 있었습니다.

그리고 설정이 되어있지 않다면 H2를 메모리 방식으로 동작하는것을 의도해서

코드를 아래와같이 했었습니다.

	
    @Bean("xxxDS")
    @Primary
    @ConfigurationProperties(prefix = "engine.ds")
    public DataSource xxxDS() {
        HikariDataSource ds = DataSourceBuilder.create().type(HikariDataSource.class).build();
        if(!ds.isRunning()){
            ds = memDataSource();
        }

        return ds;
    }

그런데 아래와 같이 에러가 떨어집니다..

HikariDataSource를 보니 HikariConfig를 생성자로 받아 생성된경우거나 getConnection()이 한번 불려서 seal처리가 되어있어서 setter를 부를수 없어 발생하는 에러였습니다

아마도 이 경우에는 HikariConfig 를 arg로 받는 생성자가 불려 seal 처리 된거겠지요

그런데.. 저는setter를 불러준적이 없습니다..

물론 그렇다면 DataSourceBuilder쪽에서 build 할때 발생하는 거겠지요

하지만.. 실제로는 DataSourceBuilder쪽에서 build할때 리플렉션으로 setter를 부르는게 아니라

@ConfigurationProperties에 의해 이미 Bean이 된 engineDS에 setter를 부르고 있었습니다..

정리하면!

HikariDataSource ds = DataSourceBuilder.create().type(HikariDataSource.class).build();

에 생성된 ds는 빈껍데기고

체크하는 로직에 당연히 들어오니 memDataSource가 만들어진 후 memDataSource가 engineDS로 등록되었고

그후 @ConfigurationProperties에 의해 setter가 불리는 상황..

그래서 어떻게할까 하다. memDataSource를 만들때 HikariConfig를 생성자로 넘기지 않고

HikariDataSource 에 setter들을 불러 생성하면 사용하기 전까지는 seal처리가 되지 않기에 이 방법으로 우회했습니다.

어차피 기본값도 정의를 할 부분이였기 때문에..

(fastPool을 안쓰는거지요, getConnection을 보니 한번은 락을 잡지만 pool 생성후에는 잡지 않으니 문제는 없을것 같습니다.)

(추후 다른 방법을 찾으면 변경하는걸로..)

역시 어노테이션을 통한 리플렉션이 편리한건 맞지만..

동작을 모르면 예상치 못한 상황이 나온다는 교훈을... 또 얻어 갑니다.

지난번 SpringBoot에서 SpringBatch를 동작시키는데, External Class들을 잡는데 생기는 문제점들이 있어서

지난번 글에 MANIFEST.MF에 org.springframework.boot.loader.JarLauncher 가 Main-Class 에 적혀 있고

실제 개발한 코드의 메인은 Main-Class에 적힌 JarLauncher가 호출해준다는 부분을 언급했습니다.

JarLauncher 코드를 보며 클래스로더를 봤을때는 "클래스로더로 커스텀으로 구성하던지 해야겠구나" 로 생각했는데

검색해보니 역시나 해결방법은 있었습니다.

org.springframework.boot.loader.JarLauncher 말고도 빌드된 jar파일을 보면 다른 클래스들이 함께 들어있는데

다른 여러 클래스들이 있지만 Launcher 구현체 는 WarLauncher와 PropertiesLauncher 두가지가 추가로 있습니다.

org.springframework.boot.loader.PropertiesLauncher 소스를 열어보니 처음 시도하던 -cp로 잡은 클래스패스와 BOOT-INF를 같은 클래스로더로 구성하는 방식은 아니지만 클래스패스 경로를 지원하는 설정을 통해 BOOT-INF와 별도로 설정한 클래스 패스 경로를 설정할 수 있도록 작성되어있습니다

그설정은 바로 "loader.path" 입니다.

저는 실행시 -Dload.path=userLib/ 형식으로 주거나 별도 설정 파일로 영역을 열어줄 예정입니다.

"loader.path"의 특이사항으로는 해당 영역의 클래스와 jar 그리고 리소스를 모두 클래스 패스에 한번에 잡아준다는 부분이며 해당 클래스패스에 있는 Configuration 클래스들도 Bean으로 잘 등록되는것을 확인했습니다.

물론 이 부분이 해결됬다고 하더라도 추가적으로 해야할 부분은 많이 남았습니다.

외부 클래스들을 클래스 패스로 제공하면 현재는 패키지가 동일한 클래스를 테스트 했지만

다른 패키지라면 componentScan을 어떻게 제공할 것인지

xml 설정은 어떻게 커버할 것인지 등.. 하나씩 시도해보고 

막히는 부분이나 기록할 부분이 있으면 기록을 남길 예정입니다.

(작성하다보니 이건 SpringBatch 라기보다는 SpringBoot 활용 관련 이슈군요..)