]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> changed the Status of [bug
SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when
deliverSync is succesful
---------------------------------------------------------------------------------------
Key: JBESB-3772
URL:
https://issues.jboss.org/browse/JBESB-3772
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.10, 4.10 CP1, 4.11
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
Assignee: Tadayoshi Sato
Labels: esb
Fix For: 4.11 CP2
I have a number of chained async, one-way services, which all use transacted JCA (with
HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class
set on the FS-Provider of the first service (entry point into the ESB), with the intention
that, if any of async, one-way services fail, the Fault Message will be sent to my
FaultService.
One of my one-way services uses a SyncServiceInvoker to do a request-response call, in
the middle of its action pipeline to a synchronous request-response service for message
validation. The result is then used in the same pipeline to do some CBR. The problem is
that, when I pass the message to the SyncServiceInvoker (which is configured to suspend
the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected,
as the synchronous request-response service needs to pass its reply and fault message to
the caller), however, these ReplyTo and FaultTo headers never get set back to their
original value if the call succeeds. In the exception flow of SyncServiceInvoker, the
ReplyTo and FaultTo do get reset to their original value (with the remark that this is not
actually necessary, which is wrong). So, when my CBR routes the message to the next
service, the ReplyTo and FaultTo headers are null, implying that the async, one-way
services will not sent a possible Fault Message to the FaultService.
In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the
'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: