第 3 章 クラスローディングとモジュール
3.6. デプロイメントでのプログラムを用いたクラスローダーの使用
3.7.1. エンタープライズアーカイブのモジュールおよびクラスロード
エンタープライズアーカイブ (EAR) は、JAR または WAR デプロイメントのように、単一モジュールと してロードされません。これらは、複数の一意のモジュールとしてロードされます。
以下のルールによって、EAR に存在するモジュールが決定されます。
EAR アーカイブのルートにある lib/ ディレクトリーの内容はモジュールです。これは、親モ ジュールと呼ばれます。
各 WAR および EJB JAR サブデプロイメントはモジュールです。これらのモジュールの動作
は、他のモジュールおよび親モジュールの暗黙的な依存関係と同じです。
サブデプロイメントでは、親モジュールとすべての他の非 WAR サブデプロイメントに暗黙的 な依存関係が存在します。
JBoss EAP ではサブデプロイメントクラスローダーの分離がデフォルトで無効になっているため、
WAR サブデプロイメント以外の暗黙的な依存関係が発生します。親モジュールの依存関係は、サブデ プロイメントクラスローダーの分離に関係なく永続します。
重要 重要
サブデプロイメントでは、WAR サブデプロイメントに暗黙的な依存関係が存在しませ ん。他のモジュールと同様に、サブデプロイメントは、別のサブデプロイメントの明示 的な依存関係で設定できます。
サブデプロイメントクラスローダーの分離は、厳密な互換性が必要な場合に有効にできます。これは、
単一の EAR デプロイメントまたはすべての EAR デプロイメントに対して有効にできます。Jakarta EE
の仕様では、依存関係が各サブデプロイメントの MANIFEST.MF ファイルの Class-Path エントリーと して明示的に宣言されている場合を除き、移植可能なアプリケーションがお互いにアクセスできるサブ デプロイメントに依存しないことが推奨されます。
3.7.2. サブデプロイメントクラスローダーの分離
エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モ ジュールです。デフォルトでは、サブデプロイメントは他のサブデプロイメントのリソースにアクセス できます。
サブデプロイメントが他のサブデプロイメントのリソースにアクセスすることが許可されていない場合 は、厳格なサブデプロイメントの分離を有効にできます。
3.7.3. EAR 内のサブデプロイメントクラスローダーの分離を有効にする
このタスクでは、EAR の特別なデプロイメント記述子を使用して EAR デプロイメントのサブデプロイ メントクラスローダーの分離を有効にする方法を示します。アプリケーションサーバーを変更する必要 はなく、他のデプロイメントは影響を受けません。
重要 重要
サブデプロイメントクラスローダーの分離が無効であっても、WAR を依存関係として追 加することはできません。
1. デプロイメント記述子ファイルを追加します。
jboss-deployment-structure.xml デプロイメント記述子ファイルが EAR の META-INF ディレ
jboss-deployment-structure.xml デプロイメント記述子ファイルが EAR の META-INF ディレ クトリーに存在しない場合は追加し、次の内容を追加します。
<jboss-deployment-structure>
</jboss-deployment-structure>
2. <ear-subdeployments-isolated> 要素を追加します。
<ear-subdeployments-isolated> 要素が jboss-deployment-structure.xml ファイルに存在し ない場合は追加し、内容が true になるようにします。
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
この EAR デプロイメントに対してサブデプロイメントクラスローダーの分離が有効になります。つま
り、EAR のサブデプロイメントは WAR ではないサブデプロイメントごとに自動的な依存関係を持ちま せん。
3.7.4. エンタープライズアーカイブのサブデプロイメント間で共有するセッションの設
定
JBoss EAP では、EAR に含まれる WAR モジュールサブデプロイメント間でセッションを共有するよう
エンタープライズアーカイブ (EAR) を設定する機能が提供されます。この機能はデフォルトで無効にな り、EAR の META-INF/jboss-all.xml ファイルで明示的に有効にする必要があります。
重要 重要
この機能は標準的サーブレット機能ではないため、この機能が有効な場合はアプリケー ションを移植できないことがあります。
EAR 内の WAR 間で共有するセッションを有効にするには、EAR の META-INF/jboss-all.xml で shared-session-config 要素を宣言する必要があります。
例
例
: META-INF/jboss-all.xmlshared-session-config 要素は、EAR 内のすべての WAR に対して共有セッションマネージャーを設定 するために使用されます。shared-session-config 要素が存在する場合は、EAR 内のすべての WAR で 同じセッションマネージャーが共有されます。ここで行われる変更は、EAR 内に含まれるすべての WAR に影響します。
3.7.4.1.
共有セッション設定オプションのリファレンス 共有セッション設定オプションのリファレンス 例
例
: META-INF/jboss-all.xml<jboss xmlns="urn:jboss:1.0">
...
<shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
</shared-session-config>
...
</jboss>
<jboss xmlns="urn:jboss:1.0">
<shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
要素
要素 説明説明
shared-session-config 共有セッション設定のルート要素。この要素が
META-INF/jboss-all.xmlに存在しない場合は、EAR に含まれるすべ てのデプロイ済み WAR で単一のセッションマネージャーが共有 されます。
distributable 分散可能なセッションマネージャーを使用する必要があること
を指定します。スキーマのバージョン 2.0 以降では、分散不可 のセッションマネージャーがデフォルトで使用されます。バー
ジョン 1.0 では、分散可能なセッションマネージャーが、引き続
きデフォルトのセッションマネージャーになります。
max-active-sessions 許可される最大セッション数。
session-config EAR に含まれるすべてのデプロイ済み WAR に対するセッション
設定パラメーターを含みます。
session-timeout EAR に含まれるデプロイ済み WAR で作成されたすべてのセッ
ションに対するデフォルトのセッションタイムアウト間隔を定 義します。指定されたタイムアウトは、分単位の整数で表記す る必要があります。タイムアウトが 0 またはそれよりも小さい 値である場合は、コンテナーにより、セッションのデフォルト の動作がタイムアウトしなくなります。この要素が指定されな い場合は、コンテナーでデフォルトのタイムアウト期間を設定 する必要があります。
cookie-config EAR に含まれるデプロイ済み WAR により作成されたセッション
追跡クッキーを含みます。
<distributable/>
<max-active-sessions>10</max-active-sessions>
<session-config>
<session-timeout>0</session-timeout>
<cookie-config>
<name>JSESSIONID</name>
<domain>domainName</domain>
<path>/cookiePath</path>
<comment>cookie comment</comment>
<http-only>true</http-only>
<secure>true</secure>
<max-age>-1</max-age>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
<replication-config>
<cache-name>web</cache-name>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
</shared-session-config>
</jboss>
name EAR に含まれるデプロイ済み WAR により作成されたセッション 追跡クッキーに割り当てられる名前。デフォルト値は
JSESSIONIDです。
domain EAR に含まれるデプロイ済み WAR により作成されたセッション
追跡クッキーに割り当てられるドメイン名。
path EAR に含まれるデプロイ済み WAR により作成されたセッション 追跡クッキーに割り当てられるパス。
comment EAR に含まれるデプロイ済み WAR により作成されたセッション
追跡クッキーに割り当てられるコメント。
http-only EAR に含まれるデプロイ済みの WAR によって作成されたセッ
ション追跡クッキーをHttpOnlyとマークするかどうかを指定 します。
secure 対応するセッションを開始したリクエストが HTTPS ではなくプ
レーン HTTP を使用している場合であっても、EAR に含まれる
デプロイ済みの WAR によって作成されたセッション追跡クッ キーをセキュアとマークするかどうかを指定します。
max-age EAR に含まれるデプロイ済みの WAR によって作成されたセッ
ション追跡クッキーに割り当てられる有効期間 (秒単位)。デ フォルト値は-1です。
tracking-mode EAR に含まれるデプロイ済み WAR により作成されたセッション
の追跡モードを定義します。
replication-config HTTP セッションクラスタリング設定を含みます。
cache-name このオプションはクラスタリング専用です。セッションデータ
を格納する Infinispan コンテナーとキャッシュの名前を指定しま す。デフォルト値が明示的に設定されていない場合は、アプリ ケーションサーバーによってデフォルト値が決定されます。
キャッシュコンテナー内で特定のキャッシュを使用するに は、web.distのようにcontainer.cacheという形式を使用し ます。名前が修飾されてない場合は、指定されたコンテナーの デフォルトのキャッシュが使用されます。
要素
要素 説明説明
replication-granularity このオプションはクラスタリング専用です。セッションレプリ ケーションの粒度を決定します。可能な値はSESSIONと ATTRIBUTEで、デフォルト値はSESSIONです。
SESSION粒度が使用される場合は、すべてのセッション属性
がレプリケートされます (要求のスコープ内でいずれかのセッ ション属性が変更された場合)。このポリシーは、オブジェクト 参照が複数のセッション属性で共有される場合に必要です。た だし、セッション属性が非常に大きい場合や頻繁に変更されな い場合は非効率になることがあります。これは、属性が変更さ れたかどうかに関係なく、すべての属性をレプリケートする必 要があるためです。
ATTRIBUTE粒度が使用される場合は、要求のスコープ内で変
更された属性のみがレプリケートされます。オブジェクト参照 が複数のセッション属性で共有される場合、このポリシーは適 切ではありません。セッション属性が非常に大きい場合や頻繁 に変更されない場合はSESSIONよりも効率的になることがあ ります。
要素
要素 説明説明