標籤
無標籤

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

最近の作業部屋活動履歴

2020-10-23
2017-03-04
2014-10-05
2014-06-05
2014-05-26
2014-02-15
2014-02-13
2014-02-12

最近のWikiの更新 (Recent Changes)

2014-02-12
2014-02-07

Wikiガイド(Guide)

サイドバー (Side Bar)

プラグイン機構

	CommonToolsでは、Javaのサービスローダアーキテクチャに準拠した簡易プラグイン機構
	を提供しております。
	
	これは、「META-INF/services/」配下にインタフェースの完全限定名と同名のファイルを
	配置し、ファイル内に改行区切りで実装クラス名を羅列することで、アプリケーションから
	特別な方法でインスタンスを取得できるようになる機能を利用したもので、この機能は元々
	JDBC4.0のJDBCドライバのオートローディングなどで利用されているものです。
	
	CommonToolsでは、上記サービスローダアーキテクチャを利用して、簡単なプラグイン機構を
	導入しております。
	
	プラグインを作成するためには、「プラグインインタフェース」と「実装クラス」が必要です。
	
	プラグインインタフェースは、「org.dyndns.nuda.plugin.Plugable」インタフェースを継承した
	インタフェースを指します。
	
	このインタフェースには、戻り値なし、引数なしのinitメソッドのみが定義されており、プラグイン
	起動時に自動的にinitメソッドがコールされるよう設計されております。
	
	実装クラスは、プラグインインタフェースを実装して作ります。
	
	それぞれのプラグインの用途ごとの実装を行い、initメソッドに初期化用のロジックを組み込みます。
	
	これらのリソースを使って、META-INF/services/[プラグインインタフェース名]
	のファイルを作成し、ファイル内に[実装クラス名]を1行に1つ定義していきます。
	
	この状態で、「org.dyndns.nuda.plugin.PluginLoader」クラスの「loadPlugin」を以下の引数
	でコールします。
	
	>pluginLoader.loadPlugin([プラグインインタフェースのクラスインスタンス]);
	
	たとえば、作成したプラグインインタフェースが「test.hoge.TestPluginIF」であれば
	
	>pluginLoader.loadPlugin(test.hoge.TestPluginIF.class);
	
	とします。
	
	loadPluginメソッドをコールすると、META-INF/services/[プラグインインタフェースクラス名]
	内部に記述された実装クラスのinitメソッドが順次実行されていく仕組みです。
	
	※以下、上記ファイルを「サービスエントリ」と呼びます
	
	この機構は、デフォルトでsun.miscパッケージのServiceクラスを利用して上記機能を実現
	しておりますが、プロジェクトの要件などによって、tools.jarがクラスパスに存在しない場合が
	あります。
	
	その場合は、自動的に上記機能を模倣した独自ロジックによって、プラグインのロード処理
	を行います。
	
	※プラグイン機構によってロードされるサービス定義が複数存在する場合
	 (別々のjarに同様のサービスエントリが存在する場合など)は、プラグインの
	 ロード順は保障されません。
	 
	 プラグインのロード順は、クラスローダ内でのエントリ順/サービスエントリ内の実装クラス
	 記述順となりますので気を付けてください。