Actually, one more note: He STRONGLY suggests not writing any JMS code in the JMS transport at all:
<jstrachan> dkulp: don't even think of writing any JMS code within cxf, just use spring message listener container <jstrachan> you can configure the spring JMS stuff however you want <jstrachan> we use URIs in camel for example <jstrachan> seriously, delete your jms code, just use spring however you wanna use it I don't know all the details about it, but apparently if you use the Spring jms/messaging stuff, it will work with the Spring transactions and security and such which doesn't work with "pure jms" stuff. One reason we've seen for not using our JMS and instead using Camel or Mule or similar is due to the lack of spring transaction support. It might be a good idea to grab the Camel and/or ServiceMix JMS code (probably Camel) and use that as more of a starting point. Also, the latest public draft of the SOAP/JMS stuff is at: http://www.w3.org/TR/2008/WD-soapjms-20080723/ Dan On Wednesday 03 September 2008 10:23:42 am Daniel Kulp wrote: > I just asked James Strachan and he said: > > <jstrachan> dkulp: but yes, you've gotta cache sessions > <jstrachan> and consumers > > I don't know the details, but since he knows the insides of ActiveMQ pretty > well, I'd take his advise. :-) > > Dan > > On Tuesday 02 September 2008 5:00:38 pm Christian Schneider wrote: > > Hi, > > > > I am just working an a refactoring of the JMS Transport. In the module > > there is an implementation of a session cache. > > > > As we later want to switch to SpringTemplate and Spring > > ListenerContainer I want to get rid of as much pooling implementation as > > possible. > > So my question is: Do we really need a session cache. As far as I > > understood from JMS specs sessions are lightweight short lived objects. > > So I think it would not harm to create a new session for each message > > and destroy it later. The same is true for producers. > > > > The connection on the other hand has to be cached as it is costly to > > create. I think the connection could be stored as a simple attribute of > > JMSConduit or JMSDestination. > > As far as I know it is thread safe too. > > > > What is your knowledge about this? > > > > Best regards > > > > Christian -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
