Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <665469.15071273169209660.JavaMail.jira@thor>
Date: Thu, 6 May 2010 14:06:49 -0400 (EDT)
From: "Seumas Soltysik (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Updated: (CXF-2793) Provide capability for JMS client to
 specify separate ReplyTo queue and listener queue
In-Reply-To: <24554790.10071272564599745.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Seumas Soltysik updated CXF-2793:
---------------------------------

    Attachment: cxf-2793-trunk.patch

I have attached a second patch specifically for the trunk.

> Provide capability for JMS client to specify separate ReplyTo queue and listener queue
> --------------------------------------------------------------------------------------
>
>                 Key: CXF-2793
>                 URL: https://issues.apache.org/jira/browse/CXF-2793
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.1.9, 2.2.7
>            Reporter: Seumas Soltysik
>            Assignee: Willem Jiang
>             Fix For: 2.1.9, 2.2.7
>
>         Attachments: cxf-2793-trunk.patch, CXF-2793.patch
>
>
> A customer using MQSeries would like the ability to specify a queue in the ReplyTo head of an outgoing message that is different from the queue that the CXF JMS client listens to for a response. This solution is for the scenario where the JMS client and JMS server are interacting with different QueueManagers, QM1 and QM2. In this scenario, the client and and server only know about their respective local QueueManager and not the remote QM. In such an instance, if a JMS client sends a message with a reference to a local queue associated with QM1 that it is listening to in the ReplyTo header, the JMS server associated with the remote QM2 will not be able to make use of that information since it only knows about local queues. Therefore the solution is to be able to specify a ReplyTo queue associated with QM2 which the server is aware of and then listen on a queue local to the client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.