일반적으로 JavaEE 의 개발 라이프사이클은 아래와 같은 순서를 가지고 있습니다.
Edit -> Build -> Deploy -> Test
이러한 개발 과정을 신속하게 수행하기 위해 많은 노력들이 진행되어져 왔고, WebLogic 10.3에서는 FastSwap 을 이용하여 이러한 재배포과정을 줄이기 위한 기능을 제공하게 되었습니다.
JavaEE5 에서는 운영중에 클래스로더를 내리거나 인스턴스를 종료하지 않고도 클래스를 재정의하는 기능이 소개되어졌습니다. 하지만, 선언된 필드와 메소드의 변경은 불가능한 제약사항을 가지고 있었습니다. WebLogic의 FastSwap 의 이러한 제약을 없애고 동적으로 클래스를 재 정의 할 수 있도록 설계되었습니다.
즉, FastSwap 을 이용하면 클래스로더의 리로딩이 없이도 자바 클래스의 재정의가 가능해집니다.
FastSwap 을 이용하여 배포하기 위한 어플리케이션 구성
- FasSwap 은 WebLogic을 developement mode 로 구동시킬경우에만 동작합니다. Production Mode에서는 자동으로 설정이 disable 됩니다.
- Exploded Directiory 에 있는 클래스 파일의 변경만 적용됩니다.
- WEB-INF/classes 디렉토리에 있는 클래스의 변경만 지원됩니다.
FastSwap 을 Enable 시키는 방법
weblogic-applicaion.xml 파일 또는 weblogic.xml 파일에 <fast-swap> element 를 true 로 설정합니다.
<fast-swap>true</fast-swap>
or
<fast-swap>
<enabled>true</enabled>
</fast-swap>
FastSwap 동작 순서
-
FastSwap 이 디스크립터에 설정되어지면 해당 어플리케이션이 배포되는 시점에 필요한 클래스 로더가 올라가게 됩니다.
-
해당 어플리케이션의 동작을 확인하기 위해 브라우저를 기동하면, 메소드와 클래스가 수정이되고 컴파일이 수행됩니다.
-
브라우저를 리프레시하고 새로운 request 를 보냅니다.
이때 FastSwap 에이전트는 아래와 같은 경로의 클래스패스에 있는 클래스의 timestamp를 검사하여 변경이 있는지를 확인하게 됩니다.
ExampleApp/APP-INF/classes
ExampleApp/webapp/WEB-INF/classes
변경이 있을 경우 FastSwap 에이전트가 수정된 클래스를 재정의하여 요청에 대한 응답을 수행하게 됩니다.
FastSwap 을 사용 하는데 제약사항
-
Java Reflection 결과는 새롭게 변경된 필드와 메소드를 포함하지 못합니다. 따라서 수정된 클래스의 API의 reflection 을 사용하는 경우 예상치 못한 동작이 나타날 수 있습니다.
-
이미 존재하는 클래스의 계층의 변경은 지원되지 않습니다. 예를 들어 클래스의 인터페이스를 implemented 한 리스트의 변경이나 클래스의 superclass 를 변경하는 경우는 지원이 되지 않습니다.
-
Java annotation의 추가나 제거의 경우는 지원되지 않습니다. 이는 위에 언급한 reflection의 이유 때문입니다.
-
EJB 인터페이스의 메소드에대한 추가나 제거의 경우는 지원되지 않습니다. EJB 편집은 변경에 대한 reflect 가 필요하기 때문입니다.
-
Enums의 상수를 추가하거나 제거하는 경우는 지원되지 않습니다.
-
finalize mothod 에 대한 추가나 제거의 경우는 지원되지 않습니다.
지원되지 않는 변경이 있는 경우 UnsupportedOperationException 이 JVM에 뿌려지게 되고 서버로그에 남게 됩니다. 이경우 어플리케이션의 변경이 반영되지는 않지만 동작은 계속 하게 됩니다. 이 변경을 반영시키기 위해서는 해당 어플리케이션을 재배포하여 주어야 합니다.
http://blogs.oracle.com/WebLogicServer/2009/10/using_fastswap_to_speed_up_dev.html