cxf-dev mailing list archives

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

I'd like to propose to get the additional changes after 3.0.0-milestone2 
is out,

Thanks, Sergey

On 13/02/14 10:08, Christian Schneider wrote:
> 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:
> jms:jndi:dynamicQueues/test.jmstransport.text?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&replyToName=dynamicQueues/test.jmstransport.response&jndiURL=tcp://localhost:61616&jndiConnectionFactoryName=ConnectionFactory
> 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:
> jms:queue:myqueue?ConnectionFactoryName=connectionFactory&Configuration=jmsConfig
> 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:
> jms:queue:myqueue
> In this case we could look up the connection factory using a default
> name "connectionFactory" and the jmsConfiguration with default name
> "jmsConfig".
> This would use a topic for the service
> jms:topic:mytopic?replyToName=myreplyqueuename
> 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

Sergey Beryozkin

Talend Community Coders


View raw message