2011-09-20 4 views
5

Websphere 7とGlassFish 3環境の間のデプロイメントを一元化するため、GlassFishでCommonJ WorkManagerとTimerManagerを実装することにしました。しかし、それは期待どおりにはうまくいきません。GlassFishとSpring 3でのCommonJ実装の使用

は、GlassFishのドメインの<resources>セクションに以下を追加しましたhttp://commonj.myfoo.de/と(春LIBSを含む)自分のドメイン/ libフォルダにライブラリが含まれます:で発見MYFOOのCommonJの実装を使用し

を:私は次のことを行っています.xmlファイル:

<resource-ref ref="wm/default"></resource-ref> 
    <resource-ref ref="tm/default"></resource-ref> 

<custom-resource res-type="commonj.work.WorkManager" jndi-name="wm/default" factory-class="de.myfoo.commonj.work.FooWorkManagerFactory"></custom-resource> 
<custom-resource res-type="commonj.timers.TimerManager" jndi-name="tm/default" factory-class="de.myfoo.commonj.timers.FooTimerManagerFactory"></custom-resource> 

はdomain.xmlのの<servers>/<server>セクションの参照を含めます

私のテストアプリケーションのweb.xmlに適切なリソース参照を追加します。

<resource-ref> 
    <description>WorkManager</description> 
    <res-ref-name>wm/default</res-ref-name> 
    <res-type>commonj.work.WorkManager</res-type> 
    <res-auth>Container</res-auth> 
    <res-sharing-scope>Shareable</res-sharing-scope> 
</resource-ref> 

<resource-ref> 
    <description>TimerManager</description> 
    <res-ref-name>tm/default</res-ref-name> 
    <res-type>commonj.timers.TimerManager</res-type> 
    <res-auth>Container</res-auth> 
    <res-sharing-scope>Unshareable</res-sharing-scope> 
</resource-ref> 

は私のapplicationContext.xmlをに次の豆を追加します。このセットアップのすべての後

<bean id="threadTestTaskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor"> 
    <property name="workManagerName" value="wm/default" /> 
    <property name="resourceRef" value="true"/> 
</bean> 

<bean id="threadTestTimerExecutor" class="org.springframework.scheduling.commonj.TimerManagerTaskScheduler"> 
    <property name="timerManagerName" value="tm/default" /> 
    <property name="resourceRef" value="true" /> 
    <property name="shared" value="false" /> 
</bean> 

<bean id="threadTest" class="test.ThreadTester"></bean> 

<task:scheduled-tasks scheduler="threadTestTimerExecutor"> 
    <task:scheduled ref="threadTest" method="execute" fixed-delay="30000" /> <!-- 30 seconds --> 
</task:scheduled-tasks> 

を、すべてがロードされ、Webアプリケーションが実行されます。ただし、ThreadTesterクラスはTimerで実行されません。

私はmyFOOコードを実行しており、TimerManager(FooTimerManager.java)のメインループが実行されていますが、30秒ごとにクラスを起動するはずです。

私の質問:

は、誰もがGlassFishの3と春とJSR 237分の236(のCommonJ)を実装経験がありましたか?

私が使用して試してみることができるmyFOO以外の別の実装がありますか? 私は何をやろうとしましたか?あなたが成功した場合、結果を分かち合うつもりはありますか?

ありがとうございます!

編集1:

私はGlassFishのでMYFOOのCommonJの実装を使用する限りワークマネージャが懸念しているよう作業を行うことを言及するのを忘れてしまいました。 でないものは、TimerManagerです。つまり、オンデマンドでスレッドを起動できますが、トリガーされたスケジューリングは機能しません。

編集2:

のGlassFish 3.1.1にアップデートして以来、TimerManagerをのMYFOOのCommonJの実装が正常に動作しています。とても素晴らしい!この質問はHOWTOガイドのようになりました。

答えて

0

GlassFish 3.1にアップデートして以来のようです。1、私はもはやTimerManagerのmyFOO実装に問題がありません。私の@Scheduled豆は今はうまく動作しています。

0

Springで作業している場合、なぜ別のTimer実装を使用していますか? Spring scheduling integrationを使用するだけではどうですか? Springは気にしないので、あなたのアプリケーションが動作しているサーバを心配する必要はありません。

+2

私はすでにこれを行っています。春は気にします。タイマー/ワークマネージャーBeanを設定するときは、アプリケーションサーバーによって異なる実装クラスを提供する必要があります。 – faffy

+0

実際これは重要です。 Springは抽象化を提供し、作業者をコンテナ固有の実装に結びつけることができます。そうすることなく、つまり、Springが提供するものを使用するだけで、アンマネージスレッドを作成しています。 – TechTrip

2

私は、myFoo CommonJのTimerManagerを使用することをお勧めしません。約6年間休眠するだけでなく、いくつかの点でコードがちょっと変わっています(v1.1を参照)。例えば。 FooTimerクラスのisExpiredメソッドは次のようになります。

public boolean isExpired() { 
    return scheduledExcecutionTime >= System.currentTimeMillis(); 
} 

その予定の次回実行時間が未来にあるときに、タイマーが期限切れになりますか?ナンセンス - それは他の方法ラウンドする必要があります!

他の場所(TimerExecutor#run)では、現在のスレッドにモニタがないオブジェクト(TimerManager)に対してnotifyAllが呼び出され、常にjava.lang.IllegalMonitorStateExceptionsが発生します。

手を離してください!

+1

あなたは正しいかもしれませんが、代替手段はありますか?これまでのところ、myFOOの実装は私のニーズに合っています。 – faffy

関連する問題