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
