SpringBatch에 external Configuration Class 검토

JAVA/SpringBatch|2020. 4. 10. 20:12

업무상

SpringBoot 베이스로 SpringBatch 위에 조금 레이어를 추가할 계획을 가지고 있는데

 

제품 base jar에(SpringBoot 자체에 레이어를 추가한 jar) 에

클래스 패스로 추가적인 클래스(외부 개발자 혹은 고객이 개발 및 선언한 configuration class나 기타등등..)

를 더해서 돌려보면 어떨까 싶어 테스트를 시도하고 있습니다.

 

의도 했던 부분은 base jar에 추가적인 클래스를 심어 돌리면 되겠지만

관리상 base jar는 그대로 두고 추가적인 클래스는 jar로 묶거나 클래스 자체로 두고

배치 실행시 클래스패스에 base jar와 추가적인 클래스 jar를 잡아 실행 시키면 되지 않을까?

를 생각했지만 의도처럼 동작하지 않았습니다.

 

먼저 테스트로 추가해봤던 클래스는 job의 선언이 들어있는 Configuration Class 인데요

 

클래스 패스로 base와 추가된 클래스를 둘다 묶고 돌렸지만 몇가지 이슈들 만났습니다.

(일단 SpringBoot버전은 1.5.22와 2.2.5 그리고 1.3을 조금 살펴봤습니다. 1.3은 구조가 조금 달랐었습니다)

 

먼저 "java -jar boot.jar" 로 실행 했던것을 "java -cp boot.jar:app.jar com.meteor.AppMain" 방식으로 실행을 해봤는데

(실제 파일이나 옵션을 많이 생략했습니다)

 

boot.jar 내에 있는 com.meteor.AppMain 클래스를 못찾는 문제가 생겼습니다.

 

그래서 boot.jar 를 열어보니 클래스를 못찾는 이유를 알게됬는데, 디렉토리 구조가 일반적인 jar의 구조와는 많이 달랐습니다.

원래 boot.jar에 클래스가 있어야하는 바로 com 디렉토리가 보여야하는데

디렉토리 구조는

BOOT-INF

META-INF

org

였습니다.

 

META-INF는 흔한 디렉토리이고

org는 제가 생성하지 않은 클래스들이 들어있는 디렉토리 였습니다

BOOT-INF의 경우에는 하위에 classes와 lib이 있는데 classes에는

작성한 클래스들 lib에는 의존성이 걸려있는 lib들이 있었습니다.

 

위의 "java -cp boot.jar:app.jar com.meteor.AppMain" 처럼 실행했을때

com.meteor.AppMain을 찾으려면 org처럼 jar내에 바로 com 부터 있어야하는데 BOOT-INF/classes에 있으니

못찾는게 당연했습니다.

 

그럼 "java -jar boot.jar"로 호출했을때는 com.meteor.AppMain를 어떻게 찾고 있는건가?

를 살펴봤습니다.

 

일반적으로 execuexecutable jar는 META-INF의 MANIFEST.MF에 Main-Class에 있는 메인 클래스를 실행하게 됩니다.

 

그래서 boot.jar에 META-INF의 MANIFEST.MF에 Main-Class에 있는 클래스는

com.meteor.AppMain이라고 적혀있길 기대했지만

"org.springframework.boot.loader.JarLauncher" 라는 모르는 클래스가 적혀있었습니다.

그리고 "com.meteor.AppMain"는 Main-Class 에 적혀있지 않고 Start-Class 에 적혀있었습니다.

 

결국 "java-jar boot.jar" 를 호출한다면 com.meteor.AppMain이 호출되는것이 아니라 

org.springframework.boot.loader.JarLauncher것이 호출되는 것이고

내부 과정을 거쳐서 com.meteor.AppMain가 호출되는것을 예상 할수 있습니다.

 

그럼 "org.springframework.boot.loader.JarLauncher"는 무엇이고 어떻게 AppMain이 호출되는가?

를 조금 살펴봤습니다.

 

JarLauncher는 ExecutableArchiveLauncher를 상속 받고 있고 

ExecutableArchiveLauncher는 Launcher를 상속받고 있습니다.

 

당연히 JarLauncher에 main()이 있고, main 로직에는 launch(String[])를 호출하고 있고

launch(String[])은 상위에서 구현한 부분이 없기에 결국 Launcher에 launch(String[])가 불리고 코드는 하단과 같습니다.

protected void launch(String[] args) throws Exception {
    JarFile.registerUrlProtocolHandler();
    ClassLoader classLoader = createClassLoader(getClassPathArchives());
    launch(args, getMainClass(), classLoader);
  }

 

getClassPathArchives()에서는 BOOT-INF/classes/ 와 BOOT-INF/lib/의 경로를 넘기고

createClassLoader(url[])을 통해 LaunchedURLClassLoader를 만들도록 되어있습니다.

LaunchedURLClassLoader는 일단 URLClassLoader을 상속 받고 있고 당연히 상식적이게도 SystemClassLoader를 parent로 연결 시켜주는식으로 되어있습니다.

 

그후, getMainClass에서 MANIFEST.MF에 Start-Class 에 클래스를 얻어 넘기고 

launch에서는 start클래스에 메인 클래스를 부르는 MainMethodRunner를 통해 호출합니다.

(MainMethodRunner는 그냥 리플렉션으로 main(String[])를 부르는..클래스 입니다)

 

여기까지만 살펴봤을때 "JarLauncher가 결국에 Start-Class에 클래스를 리플랙션으로 부른다"

에 흐름 정도는 볼 수 있었습니다.

 

아 그렇군 그럼 "java -cp boot.jar:app.jar com.meteor.AppMain" 가 아니라

"java -cp boot.jar:app.jar org.springframework.boot.loader.JarLauncher" 를 부르면 되겠군!

이라고 생각했지만 AppMain은 불리지만 문제가 있었습니다.

app.jar에 포함되어있는 내용은 job의 선언부 즉, configuration인데 이 클래스에 Bean들을 등록하다가

org.springframework.batch.core.Step 클래스를 못찾는 문제가 발생했습니다

"응? org.springframework.batch.core.Step은 그냥 boot.jar안에 lib에 Spring-batch쪽에 있는..건데..? 왜 못찾지?"

 

사실 위에 힌트가 있습니다

클래스 못찾는 문제니 당연히 클래스 로더 이슈(클래스로더가 잘못됬다는건 아닙니다, 대부분 사람이 문제죠) 였습니다.

 

현재 Configuration클래스는 위에 -cp로 잡았기 때문에 시스템 클래스로더에 물려있습니다.

그리고 org.springframework.batch.core.Step는 아까 JarLauncher가 만든 LaunchedURLClassLoader에 물려있습니다.

그리고 서로의 관계는 LaunchedURLClassLoader의 부모로 시스템 클래스 로더로 구성되어있죠

 

일반적인 클래스로더 구조 보통 상위 클래스 로더에 있는지 찾고 내려오는 구조입니다.

(일반적으로 상위 클래스 로더는 child를 알진 못합니다.)

 

즉 Thread에 ContextClassLoader는 LaunchedURLClassLoader로 설정 했으니

LaunchedURLClassLoader를 통해 Step이든 ConfigurationClass든 다 볼수 있는건 맞지만 

 

Step만 로딩 한다면, 시스템 클래스로더에는 없으니 내려와서 LaunchedURLClassLoader 에서 찾고

ConfigurationClass를 로드 할때는 시스템 클래스로더에 있으니 바로 로딩했을겁니다.

그런데 ConfigurationClass를 막상 돌려보니 안에 Step.class가 있고 ConfigurationClass를 로딩한 시스템 클래스로더로 Step.class를 로드하니 없어서 에러가 난것으로 보입니다.

 

 

쉽게 말하면 parent클래스 로더에서 parent클래스 로더에 있는 클래스(child의 클래스를 바라보는)가 하위를 바라보니 시스템 클래스로더는 없는 클래스니 에러난거죠, JobConfig에서 Step을 참조할때 LaunchedURLClassLoader 를 쓰면 되겠지만, 에러가나는 코드는 빈등록하다 에러난거라..

 

 

일단 현상황은 이정도 이며

 

해결 방법은 여러가지가 있을테지만 아직 어떤 방법이 좋을지는 고민중입니다.

BOOT-INF 안에 넣어서 한 클래스 로더에 물리는 방법이 있고

메인을 변경해서 클래스 로더를 Flat하게 커스텀 하는 방법도.. 있을것 같고..

 

추가로 정리할 내용이 생기면 업데이트 하도록 하겠습니다.

댓글()