Java EE 모듈에는 다음의 4종류가 있다.

[그림 3.1]을 보면 Java EE 애플리케이션은 하나 이상의 Java EE 모듈과 2개의 DD로 구성된다. DD는 Java EE DD(application.xml)와 JEUS DD(jeus-application-dd.xml)로 구성된다. 이때 Java EE 모듈은 1개 이상의 동일한 타입인 컴포넌트들과 DD들로 구성되기 때문에 하나의 컴포넌트만으로도 애플리케이션을 생성할 수 있다.

Java EE 애플리케이션은 확장자가 .ear인 일반적인 JAR Archive 형식의 파일로 다음은 EAR 구성의 간단한 예이다. EAR 파일의 루트 디렉터리에는 애플리케이션에 포함된 각 모듈의 Archive 파일들과 lib, META-INF 디렉터리가 존재한다.

[그림 3.2] .ear archive의 구성

다음은 각 디렉터리에 대한 설명이다.

애플리케이션 라이브러리(lib/application)는 애플리케이션 간에 공유되는 라이브러리로 JEUS 시스템에 추가되는 시스템 라이브러리(JEUS_HOME/lib/system)와는 구별된다.

시스템 라이브러리에는 시스템에서 사용하는 라이브러리들이 위치하는 것이고, lib/application에는 애플리케이션이나 기타 사용자가 설정한 클래스(서버 Lifecycle 호출 기능, 사용자 로거, 로거의 필터, 로거의 포맷터 등)에서 사용할 라이브러리를 위한 용도이다.

lib/application에 라이브러리를 위치시키면 라이브러리 파일이 애플리케이션 간에 공유될 수 있다. 따라서 사용자가 항상 애플리케이션에 라이브러리를 함께 패키징(packaging)하지 않아도 된다. 주로 도메인이나 서버에 있는 모든 애플리케이션에서 공통으로 사용될 라이브러리를 여기에 위치시킨다. 라이브러리 형태인 JAR 파일이 올 수도 있다.

lib/application은 DOMAIN_HOME과 SERVER_HOME에 위치할 수 있다.

DOMAIN_HOME/lib/application에는 도메인 전체에서 공유할 수 있는 라이브러리를 위치시킨다. 도메인에 설치된 애플리케이션 라이브러리를 다른 머신에 있는 서버에 전달하고 싶다면 다른 머신에서 최초 도메인을 구성할 때 pack-domain 명령을 통해서 구성하면 DOMAIN_HOME/lib/application도 함께 복사된다. 그 후에 애플리케이션 라이브러리가 추가되거나 변경되는 것은 사용자가 수동으로 동기화해주어야 한다.

특정 서버에서만 사용할 애플리케이션 라이브러리를 설치하고 싶다면 SERVER_HOME/lib/application에 사용할 라이브러리를 위치시킨다. 이는 명령으로 제공하지 않고 있으니 수동으로 위치시켜주어야 한다.

클래스 로딩 방식

애플리케이션 라이브러리(lib/application)의 클래스는 JEUS 루트 클래스 로더에 의해서 로딩된다. 따라서 서버에 deploy되는 모든 애플리케이션에서 사용할 수 있다.

시스템 라이브러리(JEUS_HOME/lib/system)와 동일한 클래스 로더에서 로딩되지만, 시스템 라이브러리는 사용자가 접근해서는 안 되는 디렉터리에 존재한다. 하지만 애플리케이션 라이브러리는 사용자를 위해서 사용자가 참조해야 하는 라이브러리를 위치시키는 디렉터리로 두 디렉터리의 역할이 다르다 볼 수 있다.

애플리케이션 라이브러리는 SERVER_HOME과 DOMAIN_HOME에 존재한다.

클래스 로더에서 클래스 패스에 추가하는 순서는 SERVER_HOME/lib/application이 먼저이고, DOMAIN_HOME/lib/application이 나중이다. 따라서 SERVER_HOME과 DOMAIN_HOME에 같은 라이브러리가 존재할 경우에는 SERVER_HOME에 설치되어 있는 것이 로딩되기 때문에 DOMAIN_HOME에 존재하는 라이브러리는 무시될 수 있다.

클래스 로더에 라이브러리를 클래스 패스로 추가할 때 라이브러리 파일 이름이 같은 경우에는 서버를 부팅할 때 다음과 같은 WARNING 메시지를 출력한다.

Warning [same classpath-name] : [JEUS_HOME/domains/domain1/servers/adminServer
/lib/application/applib.jar] is registered earlier than 
[JEUS_HOME/domains/domain1/lib/application/applib.jar] in JEUSClassLoader.

애플리케이션 라이브러리는 애플리케이션뿐만 아니라 서버에 특정 클래스를 설정해서 사용할 수 있는 부분에서는 모두 사용 가능하다. 그 예로는 서버 Lifecycle 호출 기능과 사용자 로거, 로그 메시지 필터 클래스, 로그 메시지 포맷터 클래스가 있다. 여기에 설정한 클래스에서는 애플리케이션 라이브러리의 라이브러리를 참조하는 것이 아니라 해당 클래스가 lib/application에 위치해야 한다.

공유 라이브러리는 애플리케이션 간에 공유되는 라이브러리로 JEUS 시스템 라이브러리(JEUS_HOME/lib/system)와 애플리케이션 라이브러리(DOMAIN_HOME/lib/application, SERVER_HOME/lib/application)와는 구별된다.

공유 라이브러리는 JEUS 전체 시스템에 영향을 주지 않고 각 애플리케이션에서 해당 라이브러리를 사용할 것인지 여부를 설정할 수 있으며, JEUS 재기동 없이 동적으로 추가할 수도 있고, 같은 라이브러리를 여러 개의 버전으로 설치하여 선택적으로 사용할 수 있다.

공유 라이브러리는 다음과 같은 특징을 가진다.

각 라이브러리는 2개의 버전(specification, implementation)을 가질 수 있다. 이렇게 함으로써 사용자들은 같은 라이브러리의 여러 개의 버전을 설치할 수 있고, 애플리케이션이 필요한 버전을(highest, minimum or exact) Deployment Time에 동적으로 선택하게 한다.

추후에 여러 버전의 라이브러리를 지원하기 위해서는 처음부터 항상 버전을 명기하는 것을 권장하며, 단순한 use case를 위해서는 버전을 전혀 사용하지 않아도 무방하다. 버전이 명기되지 않았다면 기본적으로 0라는 버전 값으로 내부적으로 해석한다.

라이브러리 Deploy 및 설정

하나의 라이브러리는 여러 개의 JAR 파일로 구성될 수 있는데 이는 보통 공유 라이브러리 디렉터리인 JEUS_HOME/lib/shared 하위에 위치한다. 그리고 JAR 파일들은 JEUS_HOME/lib/shared/libraries.xml 설정 파일에 다음과 같이 라이브러리로 등록한다.

다음 예에서 'myLibrary'는 2.0 스펙을 구현하는 2.1 버전의 구현체로 정의하여 등록되었다. 이 라이브러리는 여러 개의 JAR 파일(commons-logging.jar, commons-util.jar 그리고 myLib -2.1 서브 디렉터리에 있는 모든 JAR 파일)로 구성되어 있다.

<library>
     <library-name>myLibrary</library-name>
     <specification-version>2.0</specification-version>
     <implementation-version>2.1</implementation-version>
     <files dir=".">
         <include name="commons-logging.jar"/>
         <include name="commons-util.jar"/>
     </files>
     <files dir="myLib-2.1"/>
</library>

다음은 설정 태그에 대한 설명이다.

애플리케이션에서 라이브러리 참조

Java EE 애플리케이션이나 Standalone 모듈은 jeus-application-dd.xml, jeus-web-dd.xml 또는 jeus-ejb-dd.xml의 Entry를 통해 등록된 공유 라이브러리를 사용할 수 있다.

다음은 공유 라이브러리 'myLibrary'를 참조하는 예이다.

<library-ref>
     <library-name>myLibrary</library-name>
</library-ref>

위의 예에서 애플리케이션은 deploy될 때 라이브러리 이름이 'myLibrary'인 라이브러리를 찾고 해당 클래스 패스를 애플리케이션 클래스 패스에 추가한다. 여러 버전의 'myLibrary'가 있는 경우, 가장 높은(highest) 버전을 선택하게 된다. 참조되는 라이브러리 버전이 설정되지 않으면, 항상 절 3.3.2. “Version Ordering Rule”에 따라 최상위 버전을 찾게 된다.

다음은 최소 버전이 필요한 경우의 예이다.

<library-ref>
     <library-name>myLibrary</library-name>
     <specification-version>2.0</specification-version>
     <implementation-version>2.0</implementation-version>
</library-ref>

다음은 정확한 버전이 필요한 경우의 예이다.

<library-ref>
     <library-name>myLibrary</library-name>
     <specification-version exact-match="true">2.0</specification-version>
     <implementation-version exact-match="true">2.1</implementation-version>
</library-ref>

다음은 정해진 스펙 버전만 설정하는 경우의 예이다. 이렇게 되면 해당 스펙 버전의 최상의 implementation 버전을 찾게 된다.

<library-ref>
     <library-name>myLibrary</library-name>
     <specification-version exact-match="true">2.0</specification-version>
</library-ref>

기본적으로 애플리케이션이 deploy될 때 참조하고 있는 라이브러리를 찾을 수 없다면 WARNING 로그를 보여주지만, deploy는 계속 진행된다. 만약 이런 동작을 원하지 않는다면 다음과 같이 'failonerror' 속성을 설정하여 deploy를 실패시킬 수 있다.

<library-ref failonerror="true">
     <library-name>myLibrary</library-name>
</library-ref>

클래스 로딩 방식

공유 라이브러리의 클래스는 어느 곳에서 라이브러리 레퍼런스(reference)를 정의하고 있느냐에 따라서 애플리케이션 클래스 로더 혹은 모듈 클래스 로더에 의해서 로딩된다.

예를 들어, 'lib1'이 jeus-application-dd.xml에서 레퍼런스로 정의되었다면 EAR 레벨의 애플리케이션 클래스 로더에 의해서 로딩된다. 하지만 jeus-web-dd.xml에 레퍼런스로 정의되었다면 웹 레벨 클래스 로더에 의해서 로딩된다.

각 애플리케이션 클래스 로더에 의해 로딩된 클래스의 경우 해당 애플리케이션에서만 국한(isolated)되며, 이는 라이브러리도 동일하게 적용된다. 따라서 클래스 인스턴스는 애플리케이션 간에 공유되지 않는다.

Version Ordering Rule

Version은 "6.2.3-b12"처럼 <fraction_part>(6.2.3)와 <string(non-fraction)_part>(-b12)를 가질 수 있다.

Version ::= <fraction_part> | <string_part> | <fraction_part> <string_part>
fraction_part ::= <integer> | <integer> "." <fraction_part>
string_part ::= <non-numeric> <character>*

Version을 ordering하는 규칙은 다음과 같다.

다음은 ordering 규칙에 따른 순서의 예이다.

6.0 < 6.2.3 < 6.2.3-b12 < 6.2.3-beta < 6.2.4