You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/02/13 11:08:10 UTC

Status of the jms transport rewrite, planned additional changes

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

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Status of the jms transport rewrite, planned additional changes

Posted by Christian Schneider <ch...@die-schneider.net>.
Yes. At least anything bigger. I will try to get the connectionfactory 
and jmsconfig lookup in but only if all tests still pass.
I will delay the removal of the old style configs till after the m2.

Christian

Am 13.02.2014 11:14, schrieb Sergey Beryozkin:
> Hi Christian
>
> I'd like to propose to get the additional changes after 
> 3.0.0-milestone2 is out,
>
> Thanks, Sergey
>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Status of the jms transport rewrite, planned additional changes

Posted by Sergey Beryozkin <sb...@gmail.com>.
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
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com