Использование реализации CommonJ с GlassFish и Spring 3 - PullRequest
Новая
       161

Использование реализации CommonJ с GlassFish и Spring 3

5 голосов
/ 20 сентября 2011

В своем стремлении объединить развертывание в средах Websphere 7 и GlassFish 3 я решил попробовать внедрить CommonJ WorkManager и TimerManager в GlassFish. Но это не совсем работает, как ожидалось. Я сделал следующее:

Используйте реализацию myFOO CommonJ, найденную по адресу: http://commonj.myfoo.de/ и включите библиотеки в папку моего домена / lib (включая библиотеки Spring)

В раздел <resources> файла glassfish domain.xml добавлено следующее: 

<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>

Включить ссылки в раздел <servers> / <server> домена.xml: 

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

Добавьте соответствующие ссылки на ресурсы в 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>

Добавьте следующие bean-компоненты в мой 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>

После всей этой настройки все загружается, находит и веб-приложение запускается; однако класс ThreadTester не запускается на таймере.

Я прошел по коду myFOO, и основной цикл TimerManager (FooTimerManager.java) работает, просто кажется, что он никогда не распознает, что каждые 30 секунд он должен запускать класс.

Мои вопросы:

Кто-нибудь имел опыт внедрения JSR 236/237 (CommonJ) со GlassFish 3 и Spring?

Есть ли другая реализация, отличная от myFOO, которую я мог бы использовать и попробовать? Кто-нибудь пытался сделать то, что я сделал? Хотели бы вы поделиться своими результатами, если вам это удалось?

Спасибо!

Редактировать 1:

Я забыл упомянуть, что использование реализации myFOO CommonJ с GlassFish работает , что касается WorkManager. не работает, это TimerManager. Это означает, что я могу запускать потоки по требованию просто отлично, но сработавшее планирование не работает.

Редактировать 2:

После обновления до GlassFish 3.1.1 реализация TimeFManager myFOO CommonJ работает нормально. Так здорово! Этот вопрос теперь больше похож на HOWTO Guide.

Ответы [ 3 ]

2 голосов
/ 15 июня 2012

Я не думаю, что было бы хорошей идеей использовать TimerManager из myFoo CommonJ - в дополнение к тому, что он неактивен около 6 лет, в некоторых моментах код просто странный (см. V1.1). Например. метод isExpired класса FooTimer выглядит следующим образом: 

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

Итак, таймер истечет, когда его запланированное время следующего выполнения будет в будущем? Ерунда - это должно быть наоборот!

В другом месте (TimerExecutor # run) notifyAll вызывается для объекта (TimerManager), для которого текущий поток не имеет монитора, постоянно вызывая java.lang.IllegalMonitorStateExceptions.

Руки прочь!

0 голосов
/ 23 марта 2012

Что ж, похоже, что после обновления до GlassFish 3.1.1 у меня больше нет проблем с реализацией myFOO в TimerManager. Теперь мои @Scheduled бобы работают просто отлично.

0 голосов
/ 21 сентября 2011

Если вы работаете в Spring, почему вы используете другую реализацию Timer? Почему бы просто не использовать интеграцию планирования Spring ? Тогда вам не нужно беспокоиться о том, на каком сервере запущено ваше приложение, так как Spring не волнует.

...