4 Replies Latest reply on Nov 12, 2009 10:52 AM by svante.p

EJBTHREE-1670 - Quartz scheduler integration failing on JBos

jaikiran Jan 9, 2009 10:08 AM

The JCA Inflow tutorial for quartz is failing against JBoss-5.0 GA. The tutorial is nothing more than a MDB configured with an ActivationConfigProperty "cronTrigger" http://jboss.org/community/docs/DOC-11724

The deployment of this MDB fails with this exception:

org.jboss.deployers.spi.DeploymentException: Error for ActivationSpec class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec as JavaBean
 at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
 at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:135)
 at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:313)
 at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:276)
 at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156)
 at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
 at org.jboss.ejb3.JmxClientKernelAbstraction.invoke(JmxClientKernelAbstraction.java:58)
 at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.createActivationSpec(JBossMessageEndpointFactory.java:287)
 at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.start(JBossMessageEndpointFactory.java:185)
 at org.jboss.ejb3.mdb.MessagingContainer.startProxies(MessagingContainer.java:204)
 at org.jboss.ejb3.mdb.MessagingContainer.lockedStart(MessagingContainer.java:173)
 at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:879)
 at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
 at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
 at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
 at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
 at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
 at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
 at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
 at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
 at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
 at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
 at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
 at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
 at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
 at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
 at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
 at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
 at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 at java.lang.Thread.run(Thread.java:595)
Caused by: java.beans.IntrospectionException: No property found for: subscriptionDurability on JavaBean: jobName=job.34.1231512906691,jobGroup=default,triggerName=trigger.35.1231512906691,triggerGroup=default,cronTrigger=0/2 * * * * ?
 at org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties(PropertyEditors.java:354)
 at org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties(PropertyEditors.java:285)
 at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:129)
 ... 63 more

The MDB activationconfigproperty just has this:

@MessageDriven(activationConfig =
{@ActivationConfigProperty(propertyName = "cronTrigger", propertyValue = "0/2 * * * * ?")})

However, as can be seen in the exception stacktrace, the "subscriptionDurability" property gets added by default to the activationConfig. The org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec can't handle this property resulting in this exception.

The subscriptionDurability gets added by default through the org.jboss.metadata.ejb.jboss.JBossMessageDrivenBeanMetaData:

public class JBossMessageDrivenBeanMetaData extends JBossEnterpriseBeanMetaData implements ITimeoutTarget
{
 .....

 /** The acknowledge mode */
 private String acknowledgeMode;

 /** The subscription durability */
 private SubscriptionDurability subscriptionDurability = SubscriptionDurability.NonDurable;

....

1. Re: EJBTHREE-1670 - Quartz scheduler integration failing on

jaikiran Jan 19, 2009 1:57 AM (in response to jaikiran)

The JCA 1.5 spec says:

B.2.1 JMS ActivationSpec JavaBean Properties
The following is a description of the recommended set of JMS ActivationSpec
JavaBean properties:

B.2.1.5 subscriptionDurability
This property applies only to endpoints (message-driven beans) that receive
messages published to a JMS Topic. ....
....
Specifying a value for the subscriptionDurability property on the ActivationSpec
JavaBean is optional. If no value is specified, NonDurable is assumed.

So i guess, the default value should be set by the JMS activation spec (which is already being done - see below) instead of the JBossMessageDrivenBeanMetadata. The JMS activation spec already handles defaulting the value to NonDurable:

package org.jboss.resource.adapter.jms.inflow;
...
public class JmsActivationSpec implements ActivationSpec
{

...
 /** The subscription durability */
 private boolean subscriptionDurability;
...
 /**
 * @return the subscriptionDurability.
 */
 public String getSubscriptionDurability()
 {
 if (subscriptionDurability)
 return "Durable";
 else
 return "NonDurable";
 }

 /**
 * @param subscriptionDurability The subscriptionDurability to set.
 */
 public void setSubscriptionDurability(String subscriptionDurability)
 {
 this.subscriptionDurability = "Durable".equals(subscriptionDurability);
 }
...
}

So to fix this issue, we have to just remove the default value setting in the JBossMessageDrivenBeanMetadata and MessageDrivenBeanMetadata:

Index: jboss/JBossMessageDrivenBeanMetaData.java
===================================================================
--- jboss/JBossMessageDrivenBeanMetaData.java (revision 82794)
+++ jboss/JBossMessageDrivenBeanMetaData.java (working copy)
@@ -76,7 +76,7 @@
 private String acknowledgeMode;

 /** The subscription durability */
- private SubscriptionDurability subscriptionDurability = SubscriptionDurability.NonDurable;
+ private SubscriptionDurability subscriptionDurability;

 /** The destination jndi name */
 private String destinationJndiName;
Index: spec/MessageDrivenBeanMetaData.java
===================================================================
--- spec/MessageDrivenBeanMetaData.java (revision 82794)
+++ spec/MessageDrivenBeanMetaData.java (working copy)
@@ -75,7 +75,7 @@
 private String acknowledgeMode;

 /** The subscription durability */
- private SubscriptionDurability subscriptionDurability = SubscriptionDurability.NonDurable;
+ private SubscriptionDurability subscriptionDurability;

 /**
 * Create a new MessageDrivenBeanMetaData.

2. Re: EJBTHREE-1670 - Quartz scheduler integration failing on

svante.p Nov 11, 2009 2:46 PM (in response to jaikiran)

I know this is a very old thread, but is there any work-arounds to this issue?
I've tried manually assigning the subscriptionDurability property both through annotations and xml but the problem persists.

Is there no possibility to run Quartz jobs on JBoss 5.0.0-GA? We can't take the risk of upgrading to 5.1 at this point.
Actions
3. Re: EJBTHREE-1670 - Quartz scheduler integration failing on

jaikiran Nov 12, 2009 3:54 AM (in response to jaikiran)

"svante.p" wrote:
I know this is a very old thread, but is there any work-arounds to this issue?

I don't see any workarounds to this issue. The issue has actually been fixed in later versions.

"svante.p" wrote:

Is there no possibility to run Quartz jobs on JBoss 5.0.0-GA? We can't take the risk of upgrading to 5.1 at this point.

I would strongly recommend that you move to 5.1.0 version. JBoss AS-5.0.0 has a major bug which results in the disk space usage shooting up and consuming the entire volume if the server keeps running http://www.jboss.org/index.html?module=bb&op=viewtopic&t=147622. However, if upgrading is not an option then probably you could get the jar containing this fix, from the maven repo and manually place it in the AS (not a very clean option).
Actions
4. Re: EJBTHREE-1670 - Quartz scheduler integration failing on

svante.p Nov 12, 2009 10:52 AM (in response to jaikiran)

Most interesting. Thank you for pointing this out.
The major issue we are facing when it comes to upgrading is that since we don't have a clear upgrade procedure yet, we risk missing some JBoss-configuration that we have done (for example logging settings etc.).
There's a risk that we forget about moving some settings xml to the new version and end up with "interesting" results on the new version.
Actions

Go to original post