1 2 Previous Next 15 Replies Latest reply: Jul 10, 2011 8:38 AM by Ales Justin RSS

What supplies the destination ActivationConfigProperty?

Scott Stark Master

Running the org.jboss.test.cts.test.MDBUnitTestCase fails with:

07:27:25,359 ERROR [AbstractKernelController] Error installing to Start: name=jb
oss.j2ee:binding=message-driven-bean,jndiName=local/SubclassMDB@25504895,plugin=
invoker,service=EJB state=Create mode=Manual requiredState=Installed
org.jboss.deployment.DeploymentException: Required config property RequiredConfi
gPropertyMetaData@e5e569[name=destination descriptions=[DescriptionMetaData@1cfd
e49[language=en]]] for messagingType 'javax.jms.MessageListener' not found in ac
tivation config [ActivationConfigProperty(maxMessages=1), ActivationConfigProper
ty(DLQMaxResent=10), ActivationConfigProperty(DLQJNDIName=queue/DLQ), Activation
ConfigProperty(useDLQ=true), ActivationConfigProperty(keepAlive=30000), Activati
onConfigProperty(providerAdapterJNDI=DefaultJMSProvider), ActivationConfigProper
ty(maxSession=15), ActivationConfigProperty(minSession=1)] ra=jboss.jca:service=
RARDeployment,name='jms-ra.rar'
 at org.jboss.resource.deployment.ActivationSpecFactory.createActivationS
pec(ActivationSpecFactory.java:95)
 at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDe
ployment.java:312)
 at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployme
nt.java:276)

Some metadata is not getting mapped correctly. Where should this be happening at?


  • 1. Re: What supplies the destination ActivationConfigProperty?
    Weston M. Price Master

    Should be done in org.jboss.ejb3.mdb.MessagingContainer. It's here that the endpoint for an MDB deployment is activated. What's probably not happening is that the RAR name is not being specified (for some reason in the metadata) and the MessagingContainer thinks it's a default JMS deployment.


  • 2. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    This is a legacy 2.0 mdb deployment though.

  • 3. Re: What supplies the destination ActivationConfigProperty?
    Weston M. Price Master

    Sorry, my bad. For 2.0 deployments this should be in

     org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory
    


    in the

     protected void createActivationSpec() method
    


    This is where the populated ActivationConfig properties get passed to the RARDeployment and the ActivationSpec gets created.

  • 4. Re: What supplies the destination ActivationConfigProperty?
    Adrian Brock Master

    This should be coming from the "getDestinationJNDIName" in
    the MessageDrivenMetaData:

    See the JBossJMSMessageEndpointFactory not the plain MEF

     /**
     * Add activation config properties
     *
     * @throws DeploymentException for any error
     */
     protected void augmentActivationConfigProperties() throws DeploymentException
     {
     super.augmentActivationConfigProperties();
    
     // Hack for old style deployments (jms)
     if (messagingTypeClass.equals(MessageListener.class))
     {
     // Old style deployment
     if (metaData.getMessagingType() == null)
     {
     checkActivationConfig("destination", metaData.getDestinationJndiName());
    


    As long as you don't specify the message-listener in the ejb-jar.xml
    then it will assume it is not a jca1.5 deployment and then create the
    activation config properties from the old JBoss/JMSContainerInvoker metadata.

  • 5. Re: What supplies the destination ActivationConfigProperty?
    Adrian Brock Master

    The problem is caused by the messaging-type getting defaulted to JMS
    in the new metadata.

    @XmlType(name="message-driven-beanType")
    public class MessageDrivenBeanMetaData extends EnterpriseBeanMetaData
    {
    ...
    
     /** The messaging type */
     private String messagingType = "javax.jms.MessageListener";
    


    this is not correct. The user must either specify it in the xml or use an annotation.

    For backwards compatibility in EJB2 we assume a non-jca container
    (i.e. JMSContainerInvoker style xml) if there is NO messaging-type.

  • 6. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    Not having the default as was in the old org.jboss.metadata.MessageDrivenMetaData was causing a class loading failure in the old mdb container as it was trying to load a null class for the type. I don't see why this is a change in behavior yet.

  • 7. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    I reverted the default and have the MessageDrivenContainer selecting the old default now, and the MDBUnitTestCase is passing. Still seeing another related error where the null class is not being dealt with correctly that I'm looking at:

    10:37:46,996 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:binding=message-inflow-driven-bean,jndiName=local/SubclassMDB@1556357403,plugin=invoker,service=EJB state=Create mode=Manual requiredState=Installed
    org.jboss.deployment.DeploymentException: Could not load messaging-type class null
     at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:52)
     at org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory.resolveMessageListener(JBossMessageEndpointFactory.java:295)
     at org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory.startService(JBossMessageEndpointFactory.java:193)
     at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)
    



  • 8. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    I added additional default hacks to the JBossMessageEndpointFactory, and am back to this exception, although the test runs. Can you look at getting the org.jboss.test.cts.test.MDBUnitTestCase running cleanly Adrian? I can't see where these unspecified values were coming from before the metadata change. There are also numerous errors coming from the jms layer about not finding a session, so it seems the shutdown on undeployment is unclean.

    org.jboss.deployment.DeploymentException: Required config property RequiredConfigPropertyMetaData@5fb8424e[name=destination descriptions=[DescriptionMetaData@629609cc[language=en]]] for messagingType 'javax.jms.MessageListener' not found in activation config [] ra=jboss.jca:service=RARDeployment,name='jms-ra.rar'
     at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:95)
     at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:312)
     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.ejb.plugins.inflow.JBossMessageEndpointFactory.createActivationSpec(JBossMessageEndpointFactory.java:453)
    



  • 9. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    I kept running into this so I added a hack to ensure the destination and destinationType properties were in the activation config. I don't see how a legacy 2.0 mdb deployment could have been providing the info needed by the JBossMessageEndpointFactory.augmentActivationConfigProperties().

     // Another hack for pre-ejb 2.1 deployments?
     else if(properties.containsKey("destination") == false)
     {
     String jndiName = metaData.getDestinationJndiName();
     if(jndiName != null)
     {
     org.jboss.metadata.ejb.spec.ActivationConfigPropertyMetaData acpmd = new
     org.jboss.metadata.ejb.spec.ActivationConfigPropertyMetaData();
     acpmd.setActivationConfigPropertyName("destination");
     acpmd.setValue(jndiName);
     ActivationConfigPropertyMetaData wrapper = new ActivationConfigPropertyMetaData(acpmd);
     properties.put("destination", wrapper);
     }
     String type = metaData.getDestinationType();
     if(type != null)
     {
     org.jboss.metadata.ejb.spec.ActivationConfigPropertyMetaData acpmd = new
     org.jboss.metadata.ejb.spec.ActivationConfigPropertyMetaData();
     acpmd.setActivationConfigPropertyName("destinationType");
     acpmd.setValue(type);
     ActivationConfigPropertyMetaData wrapper = new ActivationConfigPropertyMetaData(acpmd);
     properties.put("destinationType", wrapper);
     }
     }
    



  • 10. Re: What supplies the destination ActivationConfigProperty?
    Adrian Brock Master

    You're not listening to what I'm saying.

    It should be using the JBossJMSMessageEndpointFactory for these
    backwards compatible deployments.

    This class exists to provide backwards compatibilty for old JMS MDBs,
    the reason it is not working is because the "hack" is only enabled for old style
    deployments.

    We don't want to overwrite the activation config properties
    when the user is explicitly using JCA 1.5, e.g. maybe it is ActiveMQ or WSMQ
    inbound JMS resource adapter that has a different activation spec
    (i.e. different properties).

    Even worse, there should be nothing JMS specific in JBossMessageEndpointFactory!

    Your fix will mean other non-JMS activation specs will fail when the non-JMS rar says:
    "I don't have an activation config property called destination"

  • 11. Re: What supplies the destination ActivationConfigProperty?
    Scott Stark Master

    I still don't know what your saying then. The JBossMessageEndpointFactory is what is being used, but its not providing the required information to the rar. Look at providing the proper fix.

  • 12. Re: What supplies the destination ActivationConfigProperty?
    Adrian Brock Master

    I think I've found the problem, I'm just testing the fix now.
    The issue is in the MessageDrivenMetaData.

    It doesn't think it is JMS if there is no messaging-type

    public void isJMS()
    {
     return "javax.jms.MessageListener".equals(messagingType);
    }
    


    It should also return true for "null" (i.e. an old MDB deployment).

  • 13. Re: What supplies the destination ActivationConfigProperty?
    Adrian Brock Master

    Yes, that fixes the problem.

    It will now use the old "Standard Message Driven" container if there is no messaging-type
    which in turns means it will assume an old JMS deployment, i.e. JMSContainerInvoker
    (which is now implemented via the JBossJMS MEF).

    When you next update the snapshot for the metadata project, it will be fixed.

  • 14. Re: What supplies the destination ActivationConfigProperty?
    Jiachuan Li Newbie

    Adrian Brock 编写:

     

    Yes, that fixes the problem.

    It will now use the old "Standard Message Driven" container if there is no messaging-type
    which in turns means it will assume an old JMS deployment, i.e. JMSContainerInvoker
    (which is now implemented via the JBossJMS MEF).

    When you next update the snapshot for the metadata project, it will be fixed.

     

    Is there any one can tell me where I can download the updated snapshot jar file? the below download link can't access for me.

    http://repository.jboss.org/maven2/org/jboss/metadata/jboss-metadata/1.0.1.SP1/jboss-metadata-1.0.1.SP1.jar

    Now I facing the problem that use Jboss5.1 with ejb2.0 and we need configur the Active MQ in the ejb-jar.xml.

1 2 Previous Next