Hi Jens,
thanks for the explanation. Now I understand your use case. You need the
separate replyToDestination to tell the server to send to its local queue.
While I think this should be rather hidden from the client I can imagine
that it is necessary.
So I think you should be able to just leave out the useConduitIdSelector
and conduitIdSelectorPrefix. If you do not set these then CXF will
correlate on the message id and set up a selector that matches the
message id it sends out.
So the below config should work.
[bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"]
[property name="connectionFactory" ref="jmsConnectionFactory"/]
[property name="targetDestination"
value="queue:///out.queue?targetClient=1"/]
[property name="replyDestination" value="queue:///in.queue"/]
[property name="replyToDestination"
value="queue://oqm/in.queue"/]
[property name="receiveTimeout" value="30000"/]
[property name="messageType" value="byte"/]
[/bean]
Christian
Am 04.10.2011 09:47, schrieb Jens:
Hi Christian,
they must be set to different names because the server is listening on a
different queue at a different queue manager, and it doesn't know the local
queue manager my application is talking to. My application sends its
messages to a local queue that automatically forwards to the other queue
manager, and the server sends its messages to a local queue on the remote
queue manager that automatically forwards to my local response queue.
The configuration snippet is exactly what I have in my working setup with
CXF 2.2, so I can assure you that it can and does work. The only problem is
that CXF 2.3/4 no longer supports the useMessageIDAsCorrelationID option
that 2.2 had.
Regards,
Jens
Christian Schneider wrote:
Hi Jens,
why do you set replyDestination and replyToDestination to different
names? I don´t think that this can work.
The JMSConduit will always specify the replyDestination in the message
it sends out. So the server should always send the reply there.
When receiving the JMSConduit will use the replyToDestination if it is
set. So it will probably never receive anything.
Christian
Am 30.09.2011 15:50, schrieb Jens:
Hi Christian,
that won't work, primarily because I'm not allowed to use temporary
queues
(company policy) and the server is listening on a remote queue manager,
so
if I leave out replyToDestination it won't know where to send the reply.
Jens
Christian Schneider wrote:
Hi Jens,
why don´t you simply leave out replyDestination, replyToDestination,
useConduitIdSelector, conduitIdSelectPrefix.
Then cxf will use a temp queue for replies and the correlation should
still work. Can you try this with the newest CXF?
Christian
Am 30.09.2011 15:25, schrieb Jens:
This is what worked with 2.2 (angle brackets replaced to get through
Nabble):
[bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"]
[property name="connectionFactory" ref="jmsConnectionFactory"/]
[property name="targetDestination"
value="queue:///out.queue?targetClient=1"/]
[property name="replyDestination" value="queue:///in.queue"/]
[property name="replyToDestination"
value="queue://oqm/in.queue"/]
[property name="receiveTimeout" value="30000"/]
[property name="useConduitIdSelector" value="true"/]
[property name="conduitSelectorPrefix" value="ID:"/]
[property name="messageType" value="byte"/]
[property name="useMessageIDAsCorrelationID" value="true"/]
[/bean]
Jens
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4867722.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
