Upload
nekop
View
3.604
Download
20
Embed Size (px)
DESCRIPTION
Slide used in JBoss partner technical seminar in Red Hat Tokyo
Citation preview
JBoss AS 7 / EAP 6
modules and class loading
Takayoshi KimuraSenior Software Maintenance Engineer
Global Support Services, Red Hat
2
The Class Path is Dead.
3
4
Agenda
●クラスローディングの基本● JBoss Modulesと MSC● JBoss 6のクラスローディング●ユースケース別クラスローディング設定●まとめ
5
クラスローディングの基本
6
クラスパス
●特定のクラスローダがクラスをロードするパスを示す用語
●大抵「システムクラスパス」を指す● System Class Loaderで利用される
-classpathオプション値●ごくまれにアプリケーションクラスパス
7
クラスローダ種別
● Bootstrap Class Loader● コア API
● Extension Class Loader● Extension Mechanism
● System Class Loader● -classpath
● Application Class Loader● ユーザレベルクラスローダ
8
状況によるクラスローダの呼び名
● Initiating Class Loader● Foo.class.getClassLoader()
● Parent Class Loader● classLoader.getParent()
● Thread Context Class Loader● Thread.currentThread().
getContextClassLoader()
9
システムクラスローダ
Bootstrap
Extension
System
10
public class Test { public static void main(String... args) {
// System Class Loader System.out.println(Test.class.getClassLoader());
// System Class Loader System.out.println(ClassLoader.getSystemClassLoader());
// Extention Class Loader System.out.println(Test.class.getClassLoader().getParent());
// null == Bootstrap Class Loader System.out.println(ClassLoader.class.getClassLoader()); }}
クラスローダの確認
11
システムクラスローダ
●モノリシック●理解が簡単
12
システムクラスローダ
●同一ライブラリの異なるバージョンが扱えない
●見えてはいけないクラスやリソースが見えてしまう
●クラスローダの作りなおしによるクラスの再ロードができない
13
Java EEの階層型クラスローダ
System
EAR EAR
Container
WAR WAR
14
Java EEの階層型クラスローダ
●異なるバージョンを扱える●アプリケーション毎のクラスローダ再作成によるクラス再ロード可能
15
Java EEの階層型クラスローダ
●複雑●クラス検索が遅い●重複配置●ロード順によるデッドロック●クラス共有●問題を回避するための仕組みがさらに複雑度を増してしまう悪循環
16
以上設計ミス
17
18
JBoss Modules
19
モジュールクラスローダ
A
B1 B2
EC
DF
20
モジュールクラスローダ●モジュールひとつに対して一つのクラスローダ
●各モジュールはランタイムで必要とする依存モジュールを定義
●階層型ではなくグラフ構造●「クラスパス」は存在しない
21
JBoss Modules
●モジュールクラスローダ環境●モジュールを定義するための APIや設定ファイル
●シンプル●超高速
22
モジュール●クラスロードするときのひとまとまりの単位
●通常は jarひとつ●複数の jarや、プロパティファイルなどのリソースを含む場合も
23
モジュールの配置●ローカルモジュールディレクトリ
● $JBOSS_HOME/modules●階層化されたモジュール名と一致するディレクトリ構造
● Mavenのリポジトリと類似●モジュールのリソース (jarファイルなど )と、ディスクリプタ module.xmlを配置
24
モジュールディスクリプタmodule.xml<module xmlns="urn:jboss:module:1.1" name="org.jboss.remoting3"> <resources> <resource-root path="jboss-remoting-3.2.8.GA-redhat-1.jar"/> </resources>
<dependencies> <module name="javax.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.marshalling" export="true"/> <module name="org.jboss.sasl" services="import"/> <module name="org.jboss.xnio" export="true"/> <module name="org.jboss.xnio.nio" services="import"/> </dependencies></module>
25
importと export
A CB
A CB (+ C)
export
26
JBoss MSC
● Modular Service Container● JBoss Modules上にサービス層を提供● API
● ServiceContainer● Service● ServiceController
●サービスの追加、削除、依存関係の管理、インストール、ステート管理
27
JBoss EAP 6のクラスローディング
28
JBoss EAP 6のクラスローディング
●デプロイされたものもモジュールとなる● deployment.mywar.war● deployment.myear.ear.mywar.war● ローカルモジュールに対し、サービスモジュールと呼ばれる
●デプロイされたアプリケーションに応じて必要な依存モジュールが自動 import
● EJBが含まれていれば EJB関連の API
29
JBoss EAP 6のクラスローディング
● WARは一つのモジュール扱い● WEB-INF/classes, WEB-INF/lib内の jarは同じモジュールクラスローダでロードされる
● EAR● EAR/libは一つのモジュールとなる● サブデプロイメント同士もデフォルトで参照可能
● EE仕様には反しているが、仕様が微妙
30
デプロイメントとモジュール
EAR
EJB1.jar
EAR/lib
EJB2.jar
WARWARのみ片方向 import以前と同様、WAR内のクラスは他から参照不可
31
デプロイメントに対するクラスローディング優先順●システムモジュール
● コンテナが import
●ユーザモジュール● アプリケーションで import
●ローカルリソース●デプロイメント内リソース
32
デプロイメントに対するクラスローディングのカスタマイズ● META-INF/jboss-deployment-structure.xml
● WARの場合はWEB-INF● おすすめ
●グローバルモジュール● META-INF/MANIFEST.MF
● Dependencies: org.slf4j
33
jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment></jboss-deployment-structure>
34
EEサブシステムのグローバルモジュール
<subsystem xmlns="urn:jboss:domain:ee:1.0"> <global-modules> <module name="org.apache.commons.logging" /> <module name="org.apache.log4j" /> <module name="org.slf4j" /> </global-modules> </subsystem>
●全てのデプロイメントにシステムモジュールとして import
35
lib/extディレクトリ
● $JBOSS_HOME/lib/extディレクトリ● libディレクトリ自体にはまったく意味はない
● jarを置いても何も起こらない● Extension Mechanism
● lib/extディレクトリに jarを配置● マニフェストエントリ Extension-Listで参照
36
モジュール依存関係のデバッグ
● JMX● ローカルモジュール
● jboss.modules:type=ModuleLoader,name=LocalModuleLoader-3 dumpAllModuleInformation
● デプロイメント (サービスモジュール )● jboss.modules:type=ModuleLoader,name=Servic
eModuleLoader-5 dumpAllModuleInformation
37
コンテナ側モジュールの利用
●利用可能● Java EE関連 API● ロギング API● 拡張ポイント
●利用不可能● その他全てのサードパーティモジュール
38
ユースケース別クラスローディング設定
39
ユースケース別クラスローディング設定●プロパティファイル●既存のWAR●共有ライブラリ●他モジュールのアノテーションスキャン
40
プロパティファイル
●基本は jarにまとめてアプリケーションと一緒にデプロイ
●アプリケーションの外に置きたい場合はモジュールにする
mkdir -p $JBOSS_HOME/modules/conf/main/properties/cat $JBOSS_HOME/modules/conf/main/module.xml<module xmlns="urn:jboss:module:1.1" name="conf"> <resources> <resource-root path="properties"/> </resources></module>
41
プロパティファイル
●グローバルモジュールとして参照
<subsystem xmlns="urn:jboss:domain:ee:1.0"> <global-modules> <module name="conf" slot="main" /> </global-modules></subsystem>
42
プロパティファイル
● jboss-deployment-structure.xmlから参照
<jboss-deployment-structure> <deployment> <dependencies> <module name="conf" /> </dependencies> </deployment></jboss-deployment-structure>
43
既存のWAR
●フレームワークやライブラリを利用した多数の jarファイルを含むレガシーなWARファイル
● アプリケーション EAR/WAR内に依存 jarが全て含まれている
●基本的にはクラスローディングに関しては無修正で OK
44
共有ライブラリ
●既存のアプリケーションが共有ライブラリを利用している
● アプリケーション EAR/WAR内に依存 jarが全て含まれていない
●共有ライブラリをモジュール化●モジュール依存を定義
45
他モジュールを JBossのアノテーションスキャン対象にする● jandexを利用して jarにアノテーションインデックスを事前に作成
●アノテーションを import
<jboss-deployment-structure> <deployment> <dependencies> <module name="foo.bar" annotations="true"/> </dependencies> </deployment></jboss-deployment-structure>
46
まとめ
47
まとめ
● JBoss Modules / JBoss EAP 6のクラスローディング
● シンプル● 高速● フレキシブル
48
ThanksQuestions?