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

[그림 1.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 파일들과 APP-INF, META-INF 디렉터리가 존재한다.

[그림 1.2] .ear archive의 구성

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

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

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

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

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

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

하나의 라이브러리는 여러 개의 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>

위의 예에서, 애플리케이션은 디플로이될 때 라이브러리 이름이 'myLibrary'인 라이브러리를 찾고 해당 클래스 패스를 애플리케이션 클래스 패스에 추가한다. 여러 버전의 'myLibrary'가 있는 경우 가장 높은(highest) 버전을 선택하게 된다.

참조되는 라이브러리 버전이 설정되지 않으면, 항상 “1.2.5. 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 version을 찾게 된다.

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

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

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

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

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

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

버전은 "6.2.3-b12"처럼 fraction part(6.2.3)와 non-fraction(string) part(-b12)를 가질 수 있다.

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

버전을 Ordering하는 규칙은 다음과 같다.

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

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