J2EE Classloading best practices

TheServerSide.com - TSS Featured Entry

자바 엔터프라이즈 어플리케이션에서 클래스로더의 작동 방식을 이해하는게 꽤나 중요하다. 기본적으로 Java2 platform에서는 클래스를 찾을때 현재 context의 클래스로더에서 먼저 찾는게 아니고 상위 context의 클래스로더에 클래스가 있는지 물어보고 없는 경우에 자기 자신의 context에 있는 클래스로더에서 클래스를 찾는게 원칙이다. 하지만 servlet spec에서는 웹 어플리케이션 context의 경우에만 클래스로더에서 먼저 찾고 없는 경우 상위 context에 물어보는게 예외적인 표준으로 되어있다.
이러한 원칙적인 배경을 알고 위의 링크를 읽어보면 웹어플리케이션을 구성하는데 큰 도움이 될 것 같다.

위의 링크를 대략 요약해보면....

Declare dependencies
Make dependencies explicit. Hidden or unknown dependencies will be left behind when you move your application to another environment. Specify the dependencies in the Manifest Class-Path entry of EJB-JAR or WAR file on the libraries packaged in the same application.

클래스들의 의존관계를 명확히 쓰라고 하는데 현재 웹 어플리케이션이 사용하는 클래스가 무엇인지 jar 또는 war의 manifest에 명시하라고 한다. 하지만 웹 어플리케이션에서 암묵적으로 WEB-INF/lib/*.jar, WEB-INF/classes를 자동으로 classpath로 본다는건 다 아는 사실인걸...


Group dependencies
Ensure that all dependencies are visible at the same level or above. If you must move a library, make sure all dependencies are still visible.

모든 클래스 의존 관계를 보이게(visible)하라.. 이 말의 의미는 위에서 java2 platform의 클래스로더 작동방식과 servlet spec에 정의된 웹어플리케이션의 클래스로더 작동방식을 안 다면 이해할 수 있는 부분이다. 어떤 클래스 A가 참조할 수 있는 클래스는 A와 같은 context에 있는 클래스 또는 상위 context의 클래스들이기 때문이다. Sibling context의 클래스는 볼 수 없다.

Minimize visibility
Dependency libraries should be placed at the lowest visibility level that satisfies all dependencies.

최소한의 사용할 클래스만 보이게 배치하라는 얘기인데, 특정 context에서 필요하지 않는 클래스들은 같은 context나 상위 context에 배치하는 걸 피하여 참조되는걸 피하라는 얘기다.


Share libraries
Avoid duplicating libraries. Duplication of libraries may make debugging classloading issues a nightmare. Share classes across a set of applications by using the configuration facilities provided by your application server. For example, use the tag in the global application.xml file in OC4J to share classes across all applications.

클래스들이 서로 다른 context에서 될 수 있으면 중복되지 않게 배치하고 공통으로 사용하는 것들은 한곳으로 모으라는 얘기이다. 이건 좀 주의해야하는데 웹 어플리케이션이 restart하여 해당 웹어플리케이션에서 사용하는 모든 클래스들이 reloading되는 상황에서도 이렇게 공통 영역으로 빠져있는 클래스들은 reloading이 되지 않는다.


Keep configurations portable
Choose configuration options in the following order:
o Standard J2EE options
o Options that can be expressed within your EAR file
o Server-level options
o J2SE extension options

이건 뭘까? 구체적으로 뭔지 번뜩 떠오르지 않는군..


Use the correct loader
If you call Class.forName(), always explicitly pass the loader returned by Thread.currentThread().getContextClassLoader. If you are loading a properties file, use Thread.currentThread().getContextClassLoader().getResourceAsStream().

설명 필요없음.


Avoid hardcoding of a specific parser in your application
Use JAXP API to access the underlying XML/XSL parsers in a vendor-neutral way instead of hard coding a specific XML parser in your application.

XML/XSL 파서를 사용할 때 J2SE 1.4의 표준 API를 이용하라는 얘기다. 부연 설명을 하자면 J2SE 1.4에서는 endorsed library라고 해서 JCP 이외의 기관에서 만들어진 표준 라이브러리에 대해서는 implementation을 교체할 수 있는 메커니즘을 제공하고 있다. Java runtime의 소스를 보면 XML/XSL 관련해서 apache에서 제공하는 crimson과 xalan을 사용하고 있는 것으로 보이는데 이걸 다른 걸로 교체할 수 있다. XML/XSL관련 라이브러리를 특정 디렉토리에 모아놓고 -Djava.endorsed.dirs 로 그 디렉토리를 지정해주면 된다.


Avoid hot redeployment
Hot deployment depends upon classloaders and hot (re)depployment may introduce classloading errors. Avoid hot deployment if there is to much dependencies between applications and external libraries.

아.. 이거 참 저기 if there is to much에서 to가 혹시 too의 오타가 아닐까???
암튼.. 아무래도 too같다..
여기서 말하는 hot deployment란 웹어플리케이션에 새로운 클래스나 라이브러리를 재배치하는 경우를 말하는거 같다. 이 경우 해당 웹 어플리케이션에 속해 있는 클래스로더에서 class reloading이 일어나는데 이 경우 오류가 발생할 수 있단다. 그래서 클래스간의 의존관계가 복잡한 경우 될 수 있으면 hot deployment를 하지 말라는 얘기다.