4 Replies Latest reply on Nov 12, 2009 10:52 AM by Svante Paldan

    EJBTHREE-1670 - Quartz scheduler integration failing on JBos

    jaikiran pai Master

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

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

            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.

            • 3. Re: EJBTHREE-1670 - Quartz scheduler integration failing on
              jaikiran pai Master

               

              "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).




              • 4. Re: EJBTHREE-1670 - Quartz scheduler integration failing on
                Svante Paldan Newbie

                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.