パッケージング

□J2EEパッケージング
J2EE仕様に準拠した
「どんなアプリケーション・サーバでも通用するポータブルEAR」
を作成すること。

□J2EEパッケージング 3大原則
ルール①
 EARは、独立・自己完結させること。
 ※EAR以外のライブラリ参照や要APサーバ特有のクラスパス修正はご法度。
 ※[他のシステムのリモートメソッドを呼び出す]系の依存関係の残留はOK。

ルール②
 クラスローダ・デリゲーションモードは、APクラスローダと各WARクラスローダ、
 共に[PARENT_LAT]にすること。

ルール③
 クラスローダ・ポリシー(アイソレーション・モード)はデフォルトのままにすること。
 ※[単数(シングル)][アプリケーション]等に変更しないこと。
 ※アイソレーション・モードは、
  パッケージングが出来ていないEARへの一時的な救済策に使うもの。
 ※デフォルト設定
  アプリケーションごとにアプリケーション・クラスローダが1つで、
  さらに下位クラスローダとして、WAR毎の専用WARクラスローダが1つずつ割り当てられる。
  

□パッケージング策①/重複戦略
ターゲットアプリ:
 WebアプリとしてWARが3つ、EJBモジュールとしてejb-jarが2つ、さらに複数のライブラリを使用。
 各Webアプリは、さらにStrutsを使用。

―例①―
luv-app.ear
 |― META-INF/application.xml
 |― ejb1.jar
 |― ejb2.jar
 |― utility.jar
 |― commons-xxx.jar
 |― luv1.war
 |  |― WEB-INF/lib
 |     |- utility.jar
 |     |- commons-xxx.jar
 |     |- struts.jar
 |― luv2.war
 |  |― WEB-INF/lib
 |     |- utility.jar
 |     |- commons-xxx.jar
 |     |- struts.jar
 |― luv3.war
 |  |― WEB-INF/lib
 |     |- commons-xxx.jar
 |     |- struts.jar
 |     |- web-util.jar
―/例①―

目標: 自己完結したEAR。
使用するライブラリのうち、J2SE/EEに含まれていないものは、
全てEAR内にパッケージング。
EAR・WAR配下にそれぞれが使用するライブラリを配置。

J2EEコンテナは、EAR内に配置した各モジュールやライブラリをどうやって認識してるのか?
・WARやejb-jar系のJ2EEモジュール
  →EARのDD(DeploymentDescriptor:配置記述子)である[META-INF/application.xml]内に明記されてる。
・各WAR内の[WEB-INF/lib]以下のライブラリ
  →コンテナの担当、ってゆう仕様。
・EAR直下のJ2EEモジュールでないライブラリ
  →ただ置くだけでは、認識されない!!

上記のパッケージ構成のEARをアプリケーション・サーバにデプロイすると
各クラスローダの担当モジュールは以下の通り。

―例①:デプロイ後―
luv-app.ear
 |
 |―ejb1.jar / Application ClassLoader
 |―ejb2.jar / Application ClassLoader
 |―commons-xxx.jar
 |―utility.jar
 |
 |―luv1.war / WAR ClassLoader
 |  |
 |  |―utility.jar
 |  |―commons-xxx.jar
 |  |―struts.jar
 |
 |―luv2.war / WAR ClassLoader
 |  |
 |  |―utility.jar
 |  |―commons-xxx.jar
 |  |―struts.jar
―/例①:デプロイ後―
EJBモジュールはutility.jar等に依存する。
しかし、
utility.jarは、EJBモジュールのクラス検索対象外の
下位クラスローダ(WARクラスローダ)にロードされているため
EJBモジュールには、utility.jarを見つけられない。
結果、正常に動作しない。

□パッケージング策①/重複戦略/Bundled Optional Package
Bundled Optional Package:
 EAR内に同梱され、J2EEモジュールから使用されるライブラリ

使用する依存ライブラリーをJ2EEコンテナに教える必要がある。
→マニフェストファイルのClass-Pathエントリに必要なライブラリを定義する
 ※Class-Pathエントリに記述するパスは、EARのトップからの相対位置で指定すること。


ejb1.jar(EJBモジュール)が、utility.jar等に依存している場合

EJBモジュール内部のマニフェスト・ファイル[META-INFO/MANIFEST.MF]に使用するライブラリを宣言する
―例:ejb1.jar内のMETA-INF/MANIFEST.MF―
Manifest-Version: 1.0
Class-Path:
utility.jar
commons-xxx.jar
commons-yyy.jar
commons-zzz.jar
―/例:ejb1.jar内のMETA-INF/MANIFEST.MF―
J2EEコンテナは、J2EEモジュールである、WARとejb-jar内のマニフェストファイルをチェック。
Class-Pathエントリがあった場合、
そこに宣言されているライブラリをアプリケーション・クラスローダ配下に配置する。
※EARトップ直下に依存ライブラリがある場合、
 Class-Pathエントリには、Jarファイル名のみで指定。

※依存ライブラリの発見の仕組みは連鎖する。
 依存先ライブラリ内のマニフェストファイルに更にClass-Pathエントリがあった場合、
 依存先ライブラリの依存先ライブラリをも、アプリケーションクラスローダ下に同様に配置する。
 
※WARはライブラリじゃない
 luv1.war内のマニフェスト・ファイルに
 ----------------------
 Manifest-Version: 1.0
 class-path: luv2.war
 ----------------------
 と書いてもluv2.war内のクラスは見れない。
 WARはWebアプリであってライブラリでない。
 ※あるWar内のクラスを別のWar内で使用したい場合、
  そのクラスはUtilityJarとしてライブラリ化すべし。

※ライブラリとしてのJarの条件
 Javaのパッケージ階層構造がそのままJar内部のディレクト構造と一致していること。
 ※EJBモジュールは、条件を満たす点では、ライブラリとしてのJarである。


□パッケージング策②/ユニーク戦略
1つのEARにstruts.jarやらcommons-xxx.jarやらが重複してる
→無駄
⇒より重複をなくしてユニークなものしてしまおう ゆう戦略

luv-app.ear
 -META-INF/application.xml
 -ejb1.jar
 -ejb2.jar
 -utility.jar
 -commons-xxx.jar
 -struts.jar
 -luv1.war
 -luv2.war
 -luv3.war
  -WEB-INF/lib
   -web-util.jar

―例②:デプロイ後―
luv-app.ear
 |--ejb1.jar
|--ejb2.jar
|--utility.jar
|--commons-xxx.jar
|--struts.jar
|-


―/例②:デプロイ後―

ref:
http://www-06.ibm.com/jp/software/websphere/developer/j2ee/strategy/3.html
2008-10-31 20:19 : j2ee : コメント : 0 : トラックバック : 0 :
コメントの投稿
非公開コメント

« next  ホーム  prev »

search

ad



counter


tag cloud

category cloud