Hi Christian, no, that doesn't work, and I don't see anywhere in the new JMSConduit where that setting would be referenced.
Besides, using JMSConfigFeature is deprecated in 3.0, isn't it? (Also, it would be nice if the new transport had some debug output similar to the old one with regards to the standard JMS headers. That came in handy quite often.) Regards, Jens On 09.07.2014 Chrsitian Schneider wrote: > In JMSConfiguration we still have separate replyDestination and > replyToDestination properties. > So using the JMSConfigFeature you should still be able to set them > separately. > > Can you try this and report back if it works? > > Christian > > >Am 02.07.2014 14:54, schrieb #S-SmixDev: >> Hi all, >> >> the JMS transport in CXF 2.x supports different settings for >> replyDestination (ie. where the client looks for the reply) and >> replyToDestination (what the client writes into the ReplyTo header, ie. >> where the service provider actually sends the reply). >> >> We make heavy use of this feature because we are often sending to remote >> hosts that do not have any knowledge of our local queues. Messages get to >> the intended destination by means internal to the queueing system. I've >> been looking at the new JMS transport in 3.0 since we'll be wanting to >> upgrade at some point. However, it looks like the new transport does not >> support this scenario. Are there plans to implement the features from 2.x >> for the new transport? Will they be added back when there is demand? Do we >> need to do it ourselves? >> >> I'm just trying to get a picture of what the status is with regards to the >> new JMS transport at the moment. >> >> Thanks, >> Jens
