1 2 Previous Next 15 Replies Latest reply on Jul 10, 2011 8:38 AM by alesj

    What supplies the destination ActivationConfigProperty?

    starksm64

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

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

            This is a legacy 2.0 mdb deployment though.

            • 3. Re: What supplies the destination ActivationConfigProperty?
              weston.price

              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?

                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?

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

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

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

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

                          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?

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

                              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?

                                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?

                                  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

                                    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