Uso de una implementación de CommonJ con GlassFish y Spring 3

Question

En mi intento de unificar la implementación entre los entornos Websphere 7 y GlassFish 3, decidí intentar implementar CommonJ WorkManager y TimerManager en GlassFish. Pero no está funcionando como se esperaba. He hecho lo siguiente:

Utilice la aplicación myFoo CommonJ encontrado en: http://commonj.myfoo.de/ e incluir las bibliotecas en mi dominio carpeta/lib (incluyendo las librerías primavera)

añade el texto siguiente a la sección <resources> del dominio glassfish .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> 

Incluir las referencias en la sección <servers>/<server> de domain.xml:

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

Añadir las referencias de recursos apropiados en el web.xml de mi aplicación de prueba:

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

Añadir los siguientes granos a mi 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> 

Después de todo este montaje, todo lo que cargas encuentra y la aplicación web se ejecuta; sin embargo, la clase ThreadTester no se ejecuta en el temporizador.

He pisado el código myFOO y el bucle principal TimerManager (FooTimerManager.java) se está ejecutando, simplemente nunca parece reconocer que cada 30 segundos se supone que debe iniciar la clase.

Mis preguntas:

alguien ha tenido experiencia en la implementación de JSR 236/237 (CommonJ) con GlassFish 3 y la primavera?

¿Existe alguna otra implementación en otro lugar que myFOO que pueda usar y probar? ¿Alguien ha intentado hacer lo que hice? ¿Estaría dispuesto a compartir sus resultados si tuviera éxito?

Gracias!

Edición 1:

me olvidó mencionar que el uso de la aplicación myFoo CommonJ con GlassFish hace tratarán, en lo que respecta a la WorkManager. Lo que hace no es el trabajo es el TimerManager. Esto significa que puedo iniciar subprocesos a pedido, pero la programación activada no funciona.

Edición 2:

Desde la actualización a GlassFish 3.1.1, la puesta en práctica de la myFoo CommonJ TimerManager está trabajando muy bien. ¡Tan estupendo! Esta pregunta ahora se parece más a una guía HOWTO.

Answer 1

Bueno, así se ve desde la actualización a GlassFish 3.1.1, ya no tengo el problema con la implementación myFOO del TimerManager. Mis @Scheduled frijoles están funcionando bien ahora.

Answer 2

Si está trabajando en Spring, ¿por qué está utilizando otra implementación de Timer? ¿Por qué no usar el Spring scheduling integration? Entonces no tiene que preocuparse por en qué servidor se está ejecutando su aplicación, ya que a Spring no le importa.

Answer 3

No creo que sea una buena idea utilizar el TimerManager de myFoo CommonJ: además de estar latente durante unos 6 años, el código es extraño en algunos puntos (en referencia a v1.1). P.ej. el método de la clase isExpired FooTimer se ve así:

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

Así, el temporizador expira cuando su hora de la próxima ejecución programada es en el futuro? Tonterías: ¡eso debería ser al revés!

En otro lugar (TimerExecutor # run), notifyAll se invoca en un objeto (TimerManager) que el hilo actual no tiene monitor, causando constantemente java.lang.IllegalMonitorStateExceptions.

Manos fuera!