You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by #S-SmixDev <sm...@dzbank.de> on 2014/07/02 14:54:38 UTC
JMS transport in 3.0 and JMSReplyTo
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
Re: JMS transport in 3.0 and JMSReplyTo
Posted by #S-SmixDev <sm...@dzbank.de>.
Hi Christian,
no, that doesn't work, and I don't see anywhere in JMSConduit where that
setting is referenced any more.
Also, using JMSConfigFeature is deprecated with 3.0, isn't it?
(It would be nice if the new implementation had debug output similar to the
old transport for some of the standard JMS headers, too. That came in handy
quite often.)
Regards,
Jens
Von: Christian Schneider <ch...@die-schneider.net>
An: users@cxf.apache.org,
Datum: 09.07.2014 08:54
Betreff: Re: JMS transport in 3.0 and JMSReplyTo
Gesendet von: Christian Schneider <cs...@gmail.com>
On 09.07.2014 Chsristian 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
Re: JMS transport in 3.0 and JMSReplyTo
Posted by #S-SmixDev <sm...@dzbank.de>.
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
Re: JMS transport in 3.0 and JMSReplyTo
Posted by Christian Schneider <ch...@die-schneider.net>.
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
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com