[
https://issues.apache.org/jira/browse/CXF-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663611#action_12663611
]
Ron Gavlin commented on CXF-1978:
---------------------------------
Hi Christian,
I believe the smx-jms provider endpoint uses Spring JMS in a manner similar to
the CXF JMSConduit.
You might take a look at the processInOutInSession() method of the following
source file to see the technique it uses to set the JMSCorrelationID and the
corresponding message selector:
http://fisheye6.atlassian.com/browse/~raw,r=734086/servicemix/components/bindings/servicemix-jms/trunk/src/main/java/org/apache/servicemix/jms/endpoints/JmsProviderEndpoint.java.
Of course, if no replyTo destination is supplied, then a temporary replyTo
destination is constructed and subsequently used. Is the same technique
applicable here?
Regards,
/Ron
> Spring-based JMS Conduit should support using a shared permanent reply queue
> for several instances
> --------------------------------------------------------------------------------------------------
>
> Key: CXF-1978
> URL: https://issues.apache.org/jira/browse/CXF-1978
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.0.9, 2.1.3
> Reporter: Ron Gavlin
>
> The new Spring-based JMS Conduit should support using a shared permanent
> reply queue for several instances. The problem with temporary replyTo queues
> is that it is difficult to semantically associate the temporary replyTo
> queues with their original "request" queues. Using a named replyTo queue with
> a selector based on the correlationId solves this problem. This may be
> considered a "regression" introduced during the upgrade from CXF 2.1.2 to
> 2.1.3.
> See Nabble Thread
> http://www.nabble.com/forum/ViewPost.jtp?post=20447067&framed=y.
> /Ron
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
