|
While trying to support JMS proxy services for Synapse, I came across a few issues with the current JMS support in Axis2 The current Axis2 support for JMS requires you to define the destination (queue or topic) at the transport receiver level. e.g. <transportReceiver name="jms" class="org.apache.axis2.transport.jms.SimpleJMSListener"> <parameter name="transport.jms.Destination" locked="false">dynamicQueues/InvesbotJMSProxy</parameter> <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter> </transportReceiver> This seems to have two limitations, as you could only define the transport receiver for JMS (with the name "jms") only once, and there you need to specify the (single) JMS destination. Hence being able to listen for JMS messages on more than one destination is confusing and probably not properly supported? If I deploy the above configuration and two services to use the JMS transport, for both of them I get the same EPR as follows, which is a defect jms:/dynamicQueues/InvesbotJMSProxy?transport.jms.Destination=dynamicQueues/InvesbotJMSProxy &java.naming.provider.url=""> Once a message arrives at the above destination, it does not get dispatched to either service, and currently results in a service not found fault. Proposal I think that the transportReceiver for JMS should just define just the JMS connection properties (without specifying a destination). It would be good to be able to support more than one such connection, so that we could connect to multiple JMS servers in future. e.g. <transportReceiver name="jms" name="connector1" class="org.apache.axis2.transport.jms.JMSConnector"> [<parameter name="transport.jms.DestinationPrefix" locked="false">some/queuePrefix</parameter>] <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter> </transportReceiver> Then a service should get the EPR as jms://[${transport.jms.DestinationPrefix}]/<serviceName>? &java.naming.provider.url=""> A service.xml should be able to specify an optional property JMS_DESTINATION_TYPE as either a QUEUE or TOPIC and optionally the name of the destination through which it wishes to receive messages via a JMS_DESTINATION_NAME property. If these are specified, it should override the use of the service name in the destination and the EPR would be of the form jms://${JMS_DESTINATION_NAME}?&java.naming.provider.url=""> &java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory If the destination type was not specified, we should default to a Queue (probably?). The dispatcher should then use the JMS destination to determine the service to dispatch to. I would be performing some changes to accommodate the above, and also support JMS Map, Byte and Text messages in Axis2 - of which I will keep the list posted on the specifics soon. asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
- [Axis2] JMS enhancements for Axis2 Asankha C. Perera
- Re: [Axis2] JMS enhancements for Axis2 Davanum Srinivas
