I am not sure if the below issues have been addressed. But I found them in the SJMS source code (f103b8b) I downloaded and I had to fix them in my local build to make it work.
1) SjmsEndpoint.getDestinationName() should return a clean destination name that just contains the quque/topic name. However it returns queue/topic name plus all parameters which causes the JMS provider I use to fail to create the consumer due to the additional "?param1=value1&param2=value2..." text in the destination name. 2) In DefaultConsumer.MessageConsumerPool.destroyObject() method, the model.getMessageConsumer().setMessageListener(null) call causes exceptions since the messageListener in MessageConsumer is final for the JMS provider I use. I think this call is unnecessary and should be removed. Also I think SJMS could borrow the close methods in org.springframework.jms.support.JmsUtils whose interfaces are defined in terms of standard JMS API and use them in various implementations of the ObjectPool.destroyObject() method. 3) DefaultConnectionResource does support setting the JMS clientId using the connectionId property but this connectionId/clientId property is not exposed as a SjmeComponent/SjmeEndpoint property so the end user can't really set the JMS clientId. 4) The CLIENT_ACKNOWLEDGE SessionAcknowledgementType doesn't work. When I use this acknowledgementMode, all messages that have been successfully processed by Camel routes stay in the queue afterwards. At least it should work in the same fashion as camel-jms component where processed messages should only stay in the queue if unhandled exceptions are thrown during processing by camel. -- View this message in context: http://camel.465427.n5.nabble.com/SJMS-Issues-tp5716996.html Sent from the Camel Development mailing list archive at Nabble.com.
