cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Status of the jms transport rewrite, planned additional changes
Date Thu, 13 Feb 2014 10:08:10 GMT
Hi all,

I have finished one part of my rewrite of the jms transport:

- The spring dependencies are now gone. So the jms transport now only 
depends on the jms and jta specs as external libs.
- I have replaced the DefaultMessageListenerContainer with a simpler 
implementation. It uses one connection, one consumer and an 
ExecutorService. I am currently asking on the activemq list what I need 
to add to this for performance.
- As we are not using spring I removed the spring transaction support
- Currently there is no JTA transaction support but I plan to add it 
again. As I am not experienced in JTA and XA transactions I might need 
some help here. Any specialists?
- I removed the JMSEndpointType that is generated from XSD and replaced 
it by a simple Java bean in JMSEndpoint. I hope the xml serialization is 
not needed anywhere. If it is please speak up.

Now to my planned changes:

There are currently three ways to configure jms:

- Old style cxf proprietary config using conduit and wsdl extensors that 
were cxf specific
- JmsConfiguration which is also proprietary but allows some more 
injection friendly config
- SOAP/JMS spec support which combines some standardized wsdl extensors 
and uri based config

So I plan to:
1. Remove the old style config support as the soap/jms support should be 
a good replacement for it
2. Extend the uri based config with some context based resolver.

Some more details about the context based resolver:

The current uri based config looks like this:

This is very verbose, requires jndi and does not fit well into a spring 
or blueprint config.

So I propose to lookup the connection factory and optionally a 
JmsConfiguration in the blueprint or spring context using the existing 
ConfiguredBeanLocator. A config with this style could look like this:


So this would lookup the connection factory in the context using its 
bean id "connectionFactory". The jmsConfig would be also looked up by 
bean id.
The queue "myqueue" would be resolved by dynamic creation using the jms 
session like it is already done.

We could even shorten this to:

In this case we could look up the connection factory using a default 
name "connectionFactory" and the jmsConfiguration with default name 

This would use a topic for the service

As far as I can say my proposed changes should be compatible with the 
spec even if they are not portable. I would be very happy to get some 
feedback about this and perhaps alternative designs.

For people that do not use blueprint or spring we should supply a 
ConfiguredBeanLocator that can be used as a kind of registry. So you can 
just put java objects into it.


Christian Schneider

Open Source Architect

View raw message