Good work Scott! Keep it up... Best, Christian
On Wed, Aug 8, 2012 at 6:35 PM, Scott England-Sullivan <sully6...@gmail.com>wrote: > Hi and thanks for the feedback. I have put comments inline with your notes > below. > > > On Wed, Aug 8, 2012 at 11:03 AM, northface01 <northfac...@gmail.com> > wrote: > > > 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. > > > > I see the error. I will roll it into a new update. > > > > 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. > > > > Good suggestion. I will take a look at it. > > > > > > 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. > > > > This has been fixed in the latest update. There is a new > ConnectionFactoryResource (was DefaultConnectionResource) that contains the > setter for the "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. > > > > WIKI has been updated. CLIENT_ACKNOWLEDGE is not supported at this time. > I don't have a strong set of use cases yet for its use so it has been > difficult for me to find the correct home for a client acknowledgement > strategy. It is on the radar though. > > > > > > > > -- > > 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. > > > > > > -- > -- > Scott England-Sullivan > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://sully6768.blogspot.com > Twitter: sully6768 > --
