2012-03-23 13 views
1

私は、applicationContext.xmlXmlWebApplicationContextContextLoaderListenerによってロードされたSpring Webアプリケーションを持っています。アプリケーションコンテキストには、(SchedulerFactoryBeanと定義されたhereのような)クォーツスケジューラがありますが、トリガもジョブの詳細もありません。Quartzジョブを複数のApplicationContext環境で実行するにはどうすればよいですか?

このメインアプリケーションコンテキストの読み込み中に、独自のpluginApplicationContext.xmlファイルを含む「プラグイン」JARを読み込みます。 各pluginApplicationContext.xmlは、の子としてGenericXmlApplicationContextにロードされています。XmlWebApplicationContext

これらのプラグインには、前述のスケジューラ内でスケジュールされたQuartzジョブ(QuartzJobBean)が含まれている場合があります。スケジューリングはQuartz APIを介してプログラムで実行する必要がありますが、これは問題ありません。ジョブがトリガーされると、Quartzによってインスタンス化され、QuartzJobBeanが拡張されるため、現在ApplicationContextからsetApplicationContextまで取得できます。 問題は、ジョブがスケジュールされているGenericXmlApplicationContextの代わりにXmlWebApplicationContextが表示されることです。したがって、getBeanを呼び出して、プラグイン内で定義されたBeanを取得することはできません。

私はこれがなぜ起こるのかよく分かります。しかし、私はそれを処理するための清潔で再利用可能なソリューションを見つけることができません。私はすでにOSGiを見てきましたが、既存のアプリケーションにこのプラグインシステムを実装しています。新しいものを作成せず、アプリケーション全体をOSGiに移行するのはあまりにも手間がかかります。 OSGiやその他のプラグインフレームワークがこのような状況にどう対処しているか知っていますか?あなたの助けのための

おかげでたくさん

+0

私には明らかではありません。 onw pluginApplicationContext.xmlを持つプラグインがあり、プラグインで定義されているBeanがメインコンテキストからアクセスできないことを理解しています。そうですか? – jddsantaella

答えて

2

私はこれらすべての春の問題を取得するかわからないが、私は、OSGiとこれらの事をやりました。

多くの人が気づいていないことは、既存のコードに変更を加えることなく、既存のアプリケーションにOSGiを埋め込むことができるということです。リチャード・ホールは、ここでそれをhttp://felix.apache.org/site/apache-felix-framework-launching-and-embedding.htmlと記述しています(APIは100%標準化されています)。

フレームワークを使用すると、フレームワークでプラグインを実行できます。フレームワークがすべてのアプリケーションパッケージをエクスポートすることを確認する必要があります(org.osgi.framework.system.packages.extra起動プロパティを参照)。プラグインとアプリケーションは、サービスを通じて通信できます。

私は決してQuartzを使用しませんでしたが、私はスケジューリングに関するいくつかの経験があります。私は、プロパティのようにcronでのRunnableのサービスを登録します。

 
    @Component(properties="cron=1 * * * *") 
    public void SomeImpl implements Runnable { 
    public void run() { 
     ... 
    } 
    } 

あなたは、そのcronの仕様に応じて、そのサービスを呼び出すバンドルを作成する必要があります)。

+0

この**非常に興味深い記事のおかげでPeter!実際、私の問題は今解決されませんが、既存のアプリケーションに埋め込まれたプラグインシステムに関する多くの理解に役立ちます。 –

0

私は同意するのが良い方法ですが、たぶん1つの巨大なアプリケーションコンテキストを作成して(それらをすべて管理する)ことができますか?代わりに、手動で簡単に追加pluginApplicationContext.xmlファイルに基づいて新しい子アプリケーション・コンテキストを開始:

<import resource="classpath:/pluginApplicationContext.xml"/> 

そして、これはすべてのプラグインを見つけて、単一のアプリケーションコンテキストにその豆をマージします。アーキテクチャーの観点からは、これは悪いアプローチですが、起動時にすべてのプラグインを検出すると機能します。

+0

お返事ありがとうTomasz。 'pluginApplicationContext.xml'ファイルが、アプリケーションの起動時(Springより前...)にロードされたJARにある場合、このアプローチは他の' ClassLoader'sで動作しますか? JARプラグインは 'WEB-INF/lib'フォルダになく、プラグインが顧客固有のものであるためWebapp ARchiveの外側に置いておきたいのですが、Webappはそうではありません。 –

+0

@FlorentPaillard:あなたの顧客のJAR /クラスがSpringを開始する 'ClassLoader'から見える場合には動作します。試してみるのは簡単です。 –

+0

私はそれが可能ではないと思います。 Springは 'WebappClassLoader'内のサーブレットコンテナによって自動的にロードされます。私の顧客のクラス/ JARはserver/webappの標準ディレクトリの外にあるので、起動時に 'WebappClassLoader'の子である' ClassLoader'を介して "プログラムで"読み込まれなければなりません。何か不足していますか? –

関連する問題