WebLogic Server アプリケーションの開発
|
 |
 |
|
以下の節では、Java クラスローダの概要、および WebLogic Server J2EE アプリケーションのクラスローディングについて説明します。
クラスローダは、Java 言語の基本的モジュールです。クラスローダは、Java 仮想マシン (JVM) の構成要素で、クラスをメモリにロードし、実行時にクラス ファイルを検索してロードする役割があります。Java プログラミングを適切に行うためには、クラスローダとその機能をよく理解する必要があります。この節では、Java クラスローダの概要を説明します。
クラスローダには、親クラスローダおよび子クラスローダからなる階層が含まれます。親クラスローダと子クラスローダの関係は、オブジェクトのスーパークラスとサブクラスの関係に似ています。ブートストラップ クラスローダは Java クラスローダ階層のルートです。Java 仮想マシン (JVM) では、ブートストラップ クラスローダを作成し、このクラスローダによって、Java 開発キット (JDK) の内部クラスおよび JVM に組み込まれている java.* パッケージがロードされます (java.lang.String などがロードされます)。
拡張クラスローダは、ブートストラップ クラスローダの子です。拡張クラスローダは、JDK の拡張ディレクトリにあるすべての JAR ファイルをロードします。この機能は、クラスパスにエントリを追加することなく JDK を拡張できるので便利です。ただし、拡張ディレクトリ内にあるものは、すべて完全に独立している必要があり、拡張ディレクトリに含まれているクラスまたは JDK クラスしか参照できません。
システム クラスパス クラスローダは、JDK 拡張クラスローダを拡張します。システム クラスパス クラスローダは、JVM のクラスパスからクラスをロードします。アプリケーション固有のクラスローダ (WebLogic Server のクラスローダなど) は、システム クラスパス クラスローダの子です。
注意 : BEA で「システム クラスパス クラスローダ」と呼んでいるクラスローダは、多くの場合、WebLogic Server 以外の文脈上では、「アプリケーション クラスローダ」と呼ばれています。WebLogic Server におけるクラスローダについて説明する際には、J2EE アプリケーション関連のクラスローダ (「アプリケーション クラスローダ」と呼ぶ) と区別するために「システム」という用語を使用します。
クラスローダでは、クラスのロード時に委託モデルを使用します。クラスローダの実装では、まずキャッシュをチェックして、要求されたクラスがすでにロードされていないか確認します。クラスを確認することで、ディスクからクラスを繰り返しロードする代わりに、キャッシュ メモリのコピーが使用されるのでパフォーマンスが向上します。キャッシュにクラスがなければ、現在のクラスローダが親にクラスを要求します。親クラスローダがクラスをロードできない場合のみクラスローダはクラスのロードを試行します。親と子両方のクラスローダにクラスがあると、親のクラスがロードされます。この委託モデルに従うのは、複数の同じ形式のコピーがロードされることを防ぐためです。同じクラスのコピーが複数あると、ClassCastException が発生する可能性があります。
クラスローダは、親クラスローダにクラスのロードを要求してから、クラスを実際にロードします。Web アプリケーションと関連する WebLogic Server のクラスローダは、クラスを親に要求する前にまずローカルをチェックするようにコンフィグレーションできます。これにより、Web アプリケーションは独自のサードパーティ クラスを使用できるようになります。このサードパーティ クラスは、WebLogic Server 製品の一部として使用することも可能な場合があります。「prefer-web-inf-classes 要素」では、これについてより詳細に説明しています。
weblogic.xml Web アプリケーションのデプロイメント記述子には、prefer-web-inf-classes 要素 (container-descriptor 要素のサブ要素) が含まれています。デフォルトでは、この要素は False に設定されています。この要素を True に設定すると、クラスローダの委託モデルが無効になり、Web アプリケーションからのクラス定義のほうが、より高度なクラスローダのクラス定義よりも優先的にロードされるようになります。このため、Web アプリケーションは独自バージョンのサードパーティ クラスを使用できるようになります。このクラスは、WebLogic Server の一部としても使用できる場合があります。「weblogic.xml デプロイメント記述子の要素」を参照してください。
この機能を使用する場合は、Web アプリケーションのクラス定義から作成されたインスタンスと、サーバの定義から作成されたインスタンスを混在させないように注意してください。これらのインスタンスが混在していると、ClassCastException が発生します。
コード リスト 4-1 は、prefer-web-inf-classes 要素とその定義およびデフォルト値を示します。
コード リスト 4-1prefer-web-inf-classes 要素
/**
* true の場合、Web アプリケーションの WEB-INF ディレクトリ内のクラスが、アプリケーションまたはシステム クラスローダにロードされるクラスに優先してロードされる
* @default false
*/
boolean isPreferWebInfClasses();
void setPreferWebInfClasses(boolean b);
WebLogic Server では、サーバが稼働中に EJB などのアプリケーション モジュールの新しいバージョンをデプロイできます。このプロセスは、ホットデプロイ、またはホット再デプロイと呼ばれ、クラスのロードと密接な関係があります。
Java クラスローダには、クラスをアンデプロイしたり、アンロードしたりする標準メカニズムはありません。また、新しいバージョンのクラスをロードすることもできません。実行中の仮想マシンでクラスを更新するには、変更されるクラスをロードしたクラスローダを、新しいクラスローダに置き換える必要があります。クラスローダが置き換えられると、そのクラスローダ (または、そのクラスローダの子に当たるクラスローダ) からロードされたすべてのクラスを、再ロードする必要があります。また、これらのクラスのインスタンスはすべて、再インスタンス化する必要があります。
WebLogic Server では、各アプリケーションに、システム クラスローダの子に当たるクラスローダからなる階層があります。これらの階層により、アプリケーションまたはアプリケーションの一部が、システムの他の部分に影響を与えることなく個別に再ロード可能です。「WebLogic Server アプリケーションにおけるクラスローダの概要」で、このトピックについて説明しています。
この節では、WebLogic Server アプリケーション クラスローダの概要を説明します。
WebLogic Server のクラスロードは、アプリケーションの概念に基づいています。アプリケーションは、通常、アプリケーション クラスを含むエンタープライズ アーカイブ (EAR) ファイルにパッケージ化されています。EAR ファイル内にあるものは、すべて同じアプリケーションの一部と見なされます。以下のファイルは、EAR の一部になることもでき、またスタンドアロンのアプリケーションとしてロードすることも可能です。
注意 : リソース アダプタとクラスロードについては、「リソース アダプタ クラス」を参照してください。
EJB と Web アプリケーションを別々にデプロイすると、これらは 2 つのアプリケーションと見なされます。2 つのファイルをまとめて EAR ファイル内にデプロイすれば、1 つのアプリケーションとなります。したがって、複数のモジュールが同一アプリケーションの一部と見なされるためには、複数のモジュールをまとめて EAR ファイルにデプロイします。
すべてのアプリケーションは、独自のクラスローダ階層を受け取ります。この階層の親はシステム クラスパス クラスローダです。したがって、アプリケーションどうしが分離されているため、アプリケーション A からアプリケーション B のクラスローダおよびクラスを見ることはできません。階層クラスローダには、兄弟概念またはフレンド概念はありません。アプリケーション コードは、アプリケーション (またはモジュール) と関連するクラスローダでロードされたクラス、およびアプリケーション (またはモジュール) クラスローダの祖先に当たるクラスローダでロードされたクラスからしか見えません。したがって、WebLogic Server は同一の JVM 内の複数の分離したアプリケーションのホストになります。
WebLogic Server では、アプリケーションのデプロイ時にクラスローダの階層が自動的に作成されます。この階層のルート クラスローダは、アプリケーション内のすべての EJB JAR ファイルをロードします。また、Web アプリケーション WAR ファイルごとに子クラスローダが作成されます。
Web アプリケーションによる EJB の呼び出しがよくあるため、WebLogic Server アプリケーション クラスローダ アーキテクチャでは JavaServer Page (JSP) ファイルおよびサーブレットからその親クラスローダ内の EJB インタフェースを見ることができるようになっています。また、このアーキテクチャでは EJB 層を再デプロイすることなく Web アプリケーションを再デプロイできます。実際には、EJB 層ではなく JSP ファイルおよびサーブレットを変更するほうが一般的です。
次の図は、WebLogic Server アプリケーションのクラスロード概念を示しています。
アプリケーションに EJB を使用するサーブレットと JSP が含まれる場合は、次の手順に従います。
WAR ファイルと JAR ファイルは別々にデプロイできますが、まとめて 1 つの EAR ファイルにしてデプロイすることにより、サーブレットと JSP から EJB クラスを検索できるようにクラスローダが配置されます。WAR ファイルと JAR ファイルを別々にデプロイすると、WebLogic Server ではそれらのファイルごとに兄弟のクラスローダを作成します。したがって、その WAR ファイルには EJB ホームおよびリモート インタフェースを含める必要があります。WebLogic Server では、EJB クライアントと実装クラスが異なる JVM にある場合と同じように、EJB 呼び出しに RMI のスタブ クラスとスケルトン クラスを使用します。 この概念については、次節の「アプリケーション クラスロードと、値渡しまたは参照渡し」で詳しく説明しています。
注意 : Web アプリケーション クラスローダには、JSP クラスを除く、Web アプリケーションのすべてのクラスが含まれます。JSP クラスは、独自のクラスローダを取得します。これは、Web アプリケーション クラスローダの子に当たります。これにより、JSP を個別に再ロードできます。
アプリケーション用のカスタム クラスローダの階層を作成して、クラスの参照や再ロードを制御しやすくすることができます。この機能を実現するには、weblogic-application.xml デプロイメント記述子ファイルで classloader-structure 要素を定義します。
次の図は、WebLogic アプリケーションにおいてクラスローダがデフォルトではどのように構成されているかを示します。アプリケーション レベルのクラスローダは、すべての EJB クラスがロードされている場所にあります。各 Web モジュールについて、そのモジュールのクラス用の子クラスローダが個別に存在します。
簡素化のため、次の図では JSP クラスローダを示していません。
この階層は、EJB 呼び出し時に call-by reference セマンティクスを使えるようになるため、大半のアプリケーションにとって最適です。また、これにより他のモジュールに影響を与えることなく Web モジュールを個別に再ロードできるようになります。さらに、Web モジュールの 1 つで実行されているコードが、任意の EJB モジュールからのクラスをロードできるようになります。これは、使用している EJB のインタフェースが Web モジュールに含まれることを防げるので便利です。これらの利点のいくつかは、厳密には J2EE に準拠していないことに注意してください。
カスタム モジュール クラスローダを作成できると、以下のことが可能になる代替的なクラスローダ構成を宣言するメカニズムが得られます。
WebLogic 固有のアプリケーション デプロイメント記述子 weblogic-application.xml 内でクラスローダの階層を宣言できます。 デプロイメント記述子を編集する手順については、『WebLogic Builder オンライン ヘルプ』を参照してください。
<!ELEMENT classloader-structure (module-ref*, classloader-structure*)>
<!ELEMENT module-ref (module-uri)>
<!ELEMENT module-uri (#PCDATA)>
weblogic-application.xml の最上位要素には、省略可能な classloader-structure 要素が含まれます。この要素を指定しない場合は、標準のクラスローダが使用されます。また、定義の中に特定のモジュールを含めなかった場合、標準的な階層の場合と同じようにクラスローダを割り当てられます。つまり、EJB モジュールはアプリケーションのルート クラスローダと関連付けられ、Web アプリケーション モジュールは独自のクラスローダを持ちます。
classloader-structure 要素により、classloader-structure スタンザのネスティングが可能になって、クラスローダの任意階層を記述できるようになります。現在は、3 レベルに制限されています。最も外側のエントリは、アプリケーション クラスローダを示します。リストされていないモジュールについては、標準的な階層であると仮定されます。
注意 : JSP クラスローダは、この定義スキームには含まれません。JSP は常に、所属する Web モジュールと関連のクラスローダの子クラスローダにロードされます。
DTD 要素の詳細については、「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
以下は、クラスローダの宣言例です (weblogic-application.xml の classloader-structure 要素で定義)。
<classloader-structure>
<module-ref>
<module-uri>ejb1.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web3.war</module-uri>
</module-ref>
<classloader-structure>
<module-ref>
<module-uri>web1.war</module-uri>
</module-ref>
</classloader-structure>
<classloader-structure>
<module-ref>
<module-uri>ejb3.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web2.war</module-uri>
</module-ref>
<classloader-structure>
<module-ref>
<module-uri>web4.war</module-uri>
</module-ref>
</classloader-structure>
<classloader-structure>
<module-ref>
<module-uri>ejb2.jar</module-uri>
</module-ref>
</classloader-structure>
</classloader-structure>
</classloader-structure>
ネスティングの構成は、クラスローダの階層を示します。上記のスタンザにより、次の図に示す階層がもたらされます。
ユーザ定義のクラスローダの制約により、再ロードの対象とモジュール間でのクラスの参照が制御しやすくなります。この特徴は主に開発者のためのものです。繰り返しデプロイメントが行われる場合には有用ですが、プロダクション環境で使用する目的の場合には再ロード機能の使用はお勧めしません。更新時に無効な要素が含まれると、実行中のアプリケーションが破損するおそれがあるためです。ネームスペースの分離とクラス参照のためのカスタム クラスローダの配置は、プロダクション環境で使用する場合においても容認できるものです。ただし、J2EE 仕様にはアプリケーションがいかなるクラスローダ構成にも依存してはならないと書いてあることに、プログラマは注意する必要があります。
一部のクラスローダ階層は、アプリケーション内のモジュールが、2 つの別個のアプリケーションにおけるモジュールのように動作する原因となることがあります。たとえば、EJB を独自のクラスローダに配置して個別に再ロードできるようにすると、BEA が標準的なクラスローダ階層で提供している call-by-reference による最適化ではなく、call-by-value セマンティクスがもたらされることになります。また、カスタム階層を使用すると、参照が古いものになってしまう可能性があります。したがって、EJB モジュールを再ロードする場合は、呼び出し側モジュールも再ロードしてください。
ユーザ定義によるモジュール クラスローダ階層の作成には、いくつかの制約があります。これらについてはこれ以降の節で説明します。
カスタム クラスローダ階層を使用する場合は、その特定のアプリケーションにおける Web アプリケーションについては、サーブレットの再ロードは無効化されます。
カスタム クラスローダ階層を使用する場合は、その階層内の Web アプリケーションについては、prefer-web-inf-classes フラグは無視されます。
既存のクラスローダ階層内に新しい classloader-structure 要素がリーフ ノードとして追加される場合、その新しい classloader-structure に追加されるモジュールは、アプリケーション全体を再デプロイせずにデプロイできます。ただし、その階層内の既存の classloader-structure 要素を削除または再配置するときには、アプリケーション全体を再デプロイする必要があります。
既存の classloader-structure に新しい module-uri を追加する場合には、既存の module-uri の後にのみ追加するようにしてください。新しいモジュールは、アプリケーション全体を再デプロイせずにデプロイできます。ただし、module-uri を classloader-structure 要素間で移動または削除するときには、アプリケーション全体を再デプロイする必要があります。
ネスティングは、3 つのレベルまでに制限されています (アプリケーション クラスローダを含む)。ネスティングが深くなると、デプロイメント例外が発生します。
カスタム クラスローダ階層は、現在は Web および EJB モジュールに限定されています。
標準の WebLogic Server クラスローダ階層により、EJB インタフェースがアプリケーション内のすべてのモジュールで利用可能になります。したがって、それ自体のモジュールにインタフェースが含まれていなくても、他のモジュールが EJB を呼び出せます。これが可能なのは、EJB は常にルート クラスローダにロードされ、その他のモジュールはすべてそのクラスローダを共有するか、そのクラスローダの子に相当するクラスローダを持つことになるためです。
カスタム クラスローダ機能があれば、呼び出される側のクラスが呼び出し側から見えないようにクラスローダ階層をコンフィグレーションすることが可能です。この場合には、呼び出し側モジュールにインタフェース クラスを含める必要があります。これは、別個のアプリケーションのモジュールに対して呼び出しを行っている場合の要件と同じです。
WebLogic Server に設けられた標準クラスローダ階層により、アプリケーション内のモジュール間での呼び出しで call-by-reference セマンティクスを使用することが可能となります。これは、呼び出し側が常に同じクラスローダまたは呼び出される側の子クラスローダを使用しているためです。この機能により、2 つのモジュールがクラスローダ ツリーにおける別々のブランチに存在するように、クラスローダ階層をコンフィグレーションすることが可能になります。この場合、call-by-value セマンティクスが使用されます。
再ロードに必要となるクラスローダの切り替えは、複数モジュールに渡って原子性を保たないことに留意してください。実際、アプリケーションの更新は、一般に原子性を保ちません。この理由により、タイミングによっては、異なった処理中の操作 (変更が行われているときに発生している操作) が、異なったバージョンのクラスにアクセスすることになる可能性があります。
development-use-only 機能は、開発に使用することが意図されています。更新は原子性を保たないので、この機能はプロダクションに使用するには適していません。
WebLogic Server を使うと、他のモジュールを同時に再ロードして、EJB モジュール全体を再デプロイする必要なしに、個々の EJB モジュールを再ロードできます。この機能は、現在 JSP が WebLogic Server サーブレットのコンテナに再ロードされている方法に類似しています。
EJB クラスはインタフェースを通じて呼び出されるため、個々の EJB 実装クラスをそれ自身のクラスローダにロードすることが可能です。このようにして、これらのクラスは EJB モジュール全体を再デプロイすることなく個別に再ロードできます。次の図は、単一の EJB モジュールのクラスローダ階層の一例です。モジュールには、2 つの EJB (Foo および Bar) が含まれています。これは、前の節で説明した一般的なアプリケーション階層におけるサブツリーと考えられます。
図 4-4 単一の EJB モジュールのクラスローダ階層の例
展開されたアプリケーションのルートを基準とした相対的な場所にあるファイルの部分的な更新を実行するには、次のコマンドラインを使用します。
java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy myejb/foo.class
-redeploy コマンドの後で、更新したい展開アプリケーションのルートを基準として相対的にファイルのリストを指定します。これは、(上記のような) 特定の要素へのパスであっても、モジュール (または任意の要素およびモジュールのセット) へのパスであってもかまいません。次に例を示します。
コード リスト 4-5更新のための相対ファイル リストの指定
java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy mywar myejb/foo.class anotherejb
更新するファイル群を指定されると、システムは再デプロイの最小要件を計算しようとします。EJB impl クラスのみを再デプロイすると、そのクラスのみが再デプロイされることになります。EJB 全体 (上の例では anotherejb) を指定するか、または EJB ホーム インタフェースを変更して更新する場合、EJB モジュール全体の再デプロイが必要です。
クラスローダの階層によっては、この再デプロイで他のモジュールが再デプロイされることになる可能性があります。具体的には、他のモジュールが EJB クラスローダを共有しているか、(WebLogic Server の標準クラスローダ モジュールでのように) EJB のクラスローダの子クラスローダにロードされる場合は、これらのモジュールもまた再ロードされます。
最近のプログラミング言語では、パラメータを渡すときのモデルとして、値渡しと参照渡しがよく使用されます。値渡しの場合、パラメータおよび戻り値はメソッドの呼び出しごとにコピーされます。参照渡しの場合は、実際のオブジェクトを示すポインタ (または参照) がメソッドに渡されます。参照渡しでは、オブジェクトをコピーしなくてもよく、渡されたパラメータの状態を変更するメソッドも使用できるため、パフォーマンスが向上します。
WebLogic Server では、サーバ内のリモート メソッド インタフェース (RMI) 呼び出しのパフォーマンス向上のための最適化機能もあります。値渡しおよび RMI サブシステムのマーシャリングやアンマーシャリング機能を使用するのではなく、参照渡しを使用することによって、サーバがダイレクト Java メソッド呼び出しを行います。この方式により、パフォーマンスが大幅に改善され、EJB 2.0 ローカル インタフェースにもこの方式が採用されています。
RMI 呼び出しの最適化および参照呼び出しが使用されるのは、呼び出し側と呼び出された側が共に同じアプリケーションにある場合に限られます。通常、クラスローダが関係します。アプリケーションにはそれぞれ独自のクラスローダ階層があるため、どのアプリケーション クラスも両方のクラスローダに定義があり、複数のアプリケーション間で割り当てを行おうとすると ClassCastException エラーを受け取ります。この問題を回避するため、WebLogic Server では複数のアプリケーション間での呼び出しには、同じ JVM 内であっても値呼び出しを使用しています。
注意 : 複数アプリケーション間の呼び出しは、同一アプリケーション内の呼び出しに比べて遅くなります。したがって、モジュールは 1 つの EAR ファイルにまとめてデプロイし、高速の RMI 呼び出しおよび EJB 2.0 ローカル インタフェースを使用できるようにしてください。
アプリケーションでは、エンタープライズ Bean、サーブレットと JavaServer Pages、ユーティリティ クラス、およびサード パーティ製パッケージなど、さまざまな Java クラスを使用します。WebLogic Server では、個別のクラスローダにアプリケーションをデプロイして、独立を維持し、動的な再デプロイメントとアンデプロイメントを容易にします。このため、各モジュールが各クラスに個別にアクセスできるようにアプリケーションのクラスをパッケージ化する必要があります。場合によっては、一連のクラスを複数のアプリケーションまたはモジュールに格納する必要があります。この節では、アプリケーションを正常にステージングするために、WebLogic Server で複数のクラスローダを使用する方法について説明します。
このリリースの WebLogic Server では、各リソース アダプタが独自のクラスローダを使用してクラスをロードするようになりました (Web アプリケーションの場合に類似)。その結果、アプリケーション アーカイブ (EAR ファイル) でリソース アダプタと一緒にパッケージ化されている Web アプリケーションおよび EJB などのモジュールは、リソース アダプタのクラスを参照できません。そのような参照が必要な場合は、リソース アダプタのクラスを APP-INF/classes に置く必要があります。また、これらのクラスを (JAR ユーティリティを使用して) アーカイブし、それらをアプリケーション アーカイブの APP-INF/lib に置くこともできます。
リソース アダプタ固有のクラスが WebLogic Server のシステム クラスパスにないことを確認してください。リソース アダプタ固有のクラスを Web モジュール (EJB、Web アプリケーションなど) と共に使用する必要がある場合、それらのクラスを該当するモジュールのアーカイブ ファイル (EJB に使用する JAR ファイルまたは Web アプリケーションに使用する WAR ファイルなど) にまとめます。
WebLogic Server は、EAR ファイル内で共有ユーティリティ クラスを格納できる場所を提供します。ユーティリティ JAR ファイルは APP-INF/lib ディレクトリに、個々のクラスは APP-INF/classes ディレクトリに置きます (JAR ファイルを /classes ディレクトリに置いたり、クラスを /lib ディレクトリに置いたりしないでください)。これらのクラスは、アプリケーションのルート クラスローダにロードされます。
この機能により、(どちらに置くかは標準の WebLogic Server クラスローダの階層によって変わりますが) システム クラスパス内にユーティリティ クラスを置く必要や、EJB JAR ファイル内にクラスを置く必要はなくなります。この機能を使用する場合は、次の節で説明するマニフェスト Class-Path を使う場合とは少し異なることに注意してください。この機能を使うと、クラス定義はアプリケーション全体で共有されます。マニフェスト Class-Path では、参照しているモジュールのクラスパスが単純に拡張されます。つまり、クラスのコピーが別々に各モジュールについて存在するということです。
J2EE 仕様では、クラスの補助的な JAR ファイルを必要とすることをモジュールで指定する手段としてマニフェスト Class-Path エントリが用意されています。このマニフェスト Class-Path エントリを使用するのは、EJB JAR ファイルまたは WAR ファイルの一部として追加の補助的な JAR ファイルがある場合に限られます。その場合、JAR ファイルまたは WAR ファイルの作成時に、必要な JAR ファイルを参照する Class-Path 要素と共にマニフェスト ファイルを含める必要があります。
utility.jar ファイルを参照する簡単なマニフェスト ファイルを以下に示します。
Manifest-Version: 1.0 [CRLF]
Class-Path: utility.jar [CRLF]
このマニフェスト ファイルの先頭行には、常に Manifest-Version 属性を指定する必要があり、次に改行 (CR | LF |CRLF)、そして Class-Path 属性が続きます。マニフェスト フォーマットの詳細については、「http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#JAR」を参照してください。
マニフェスト Class-Path エントリは、エントリが定義されている現在のアーカイブを基準として他のアーカイブを参照します。この構造により、複数の WAR ファイルおよび EJB JAR ファイルで、共通のライブラリ JAR を共有できます。たとえば、WAR ファイルに y.jar というマニフェスト エントリが含まれる場合、このエントリは、次のように WAR ファイルの次に (中ではない) 指定されなければなりません。
/<directory>/x.war
/<directory>/y.jars
マニフェスト ファイル自体は、META-INF/MANIFEST.MF のアーカイブに配置します。
詳細については、「http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html」 を参照してください。
|
|
|
