Bug 779727 (SOA-2089)

Summary:	JBESB-3308: ReplyTo EPR must be manually reset after Aggregator action is used
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Stelios Koussouris <skoussou>
Component:	JBossESB	Assignee:	Kevin Conner <kevin.conner>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	5.0.0 GA
Target Milestone:	---
Target Release:	5.1.0.ER2
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/SOA-2089
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-01 06:34:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Stelios Koussouris 2010-05-20 11:39:11 UTC

Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=864653&gid=1354
project_key: SOA

Include fix for JBESB-3308

The ESB depends on the message's replyTo to know where to send a reply in a RequestResponse service. However, the Aggregator action makes no attempt to preserve the replyTo when it creates an aggregate message for a series. In most cases, I would think the replyTo on the aggregated messages would be the same, so adding it onto the resulting aggregated message would seem like a good idea. Otherwise, it has to be handled manually in the assembler action.

Comment 1 Stelios Koussouris 2010-05-20 11:39:34 UTC

Link: Added: This issue incorporates JBESB-3308

Comment 2 Kevin Conner 2010-09-21 14:45:21 UTC

This has already been addressed, should be present in ER1

Comment 3 David Le Sage 2011-03-01 06:08:17 UTC

Temporarily reopening to update release note info.

Comment 4 David Le Sage 2011-03-01 06:34:49 UTC

Release Notes Docs Status: Added: Documented as Resolved Issue
Writer: Added: dlesage
Release Notes Text: Added: https://issues.jboss.org/browse/JBESB-3308

The ESB depends on the message's replyTo to know where it has to send a RequestResponse service reply. However, the Aggregator action made no attempt to preserve the replyTo when it created an aggregate message for a series. To resolve this issue, it now only maps an end-point reference onto the aggregated message if all of the messages attached to the aggregated message have the same EPR.

In most cases, I would think the replyTo on the aggregated messages would be the same, so adding it onto the resulting aggregated message would seem like a good idea. Otherwise, it has to be handled manually in the assembler action.