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?

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

[starksm64]

This is a legacy 2.0 mdb deployment though.

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

[adrian.brock]

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.

[adrian.brock]

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.

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

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

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

[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);
 }
 }

[adrian.brock]

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"

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

[adrian.brock]

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

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

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