4 Replies Latest reply on Feb 7, 2007 5:10 PM by weston.price

JBAS-1434 Part 2

weston.price Jan 31, 2007 12:00 AM

Quick check of moving over to the JCA/JMS adapter. Change in standardjboss.xml is required. The easiest thing is simply to switch the default container configuration from


 <container-name>Standard Message Driven Bean</container-name>
 <call-logging>false</call-logging>
 <invoker-proxy-binding-name>message-driven-bean</invoker-proxy-binding-name>

 <container-name>Standard Message Driven Bean</container-name>
 <call-logging>false</call-logging>
 <invoker-proxy-binding-name>jms-message-inflow-driven-bean</invoker-proxy-binding-name>

Also, as we all know, the old JMSContainerInvoker allowed for creating destinations when a listener was being deployed without one. EJB3 carries this tradition over for EJB3, but for EJB 2.x the JMS/JCA adapter will not.

There are a few reasons for this

a) It's not portable and JBoss specific
b) While we could create a temporary destination using the JMS API, I don't think it is a good idea to carry this 'convenience' forward as it simply masks underlying configuration issues on the client.

In sum, you want to use JMS/JCA inflow, create your destination. Further, I am not sure how much from the JMS API without having to fall back on JBoss specific constructs to create the destination.

1. Re: JBAS-1434 Part 2

adrian.brock Jan 31, 2007 12:04 PM (in response to weston.price)

"weston.price@jboss.com" wrote:

Also, as we all know, the old JMSContainerInvoker allowed for creating destinations when a listener was being deployed without one. EJB3 carries this tradition over for EJB3, but for EJB 2.x the JMS/JCA adapter will not.

Its turned off by default in JBoss5 since it is JBossMQ specific.

There is a feature request somewhere to allow JCA admin objects
to be defined in jboss.xml which would replace this bad feature with
something more portable.
Actions
2. Re: JBAS-1434 Part 2

weston.price Jan 31, 2007 12:12 PM (in response to weston.price)

Technically, it would be nice to eliminate the JMSProviderAdapter all together and just extend the JmsActivationSpec to include the necessary information to acquire the connection factory, destination etc. This would eliminate another semi non-portable mechanism.

Again, this doesn't solve the auto create destination thing (which again, I think is just a bad idea to begin with), but it would go a long way to making the JMS/JCA adapter more relevant in other environments.
Actions
3. Re: JBAS-1434 Part 2

adrian.brock Jan 31, 2007 1:08 PM (in response to weston.price)

Yes, the modern approach should be to bind connection factories into jndi
as admin objects. You could then just reference the jndi name from
the activation config.
Actions
4. Re: JBAS-1434 Part 2

weston.price Feb 7, 2007 5:10 PM (in response to weston.price)

The JCA/JMS adatper is *ready* to move from the experimental stage at this point. I wanted this for 4.2. The only real issue at this point is the lack of a management API for the JCA/JMS adapter. It would be easy to dummy something up in the manner of the JMSContainerInvoker allowing for JMX management that simply delegates to the underlying JMSActivation. The only problem I see with this is how to uniquely identify a listener deployment. Current the JMSContainerInvoker uses the listener/jndi name combination. Obviously we don't have this with the adapter and I am not all that sure that this is the right approach. Of course the JBossMessageEndpointFactory could pass this info along in the ActivationSpec, but something just seems wrong with this.

Adding fuel to the fire is that there are two JBossMessageEndpointFactories: one for EJB3 and one for EJB2(X) deployments. We should probably combine these two and go with one approach. This is independent of the above issue.

Thoughts?
Actions

Go to original post