[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
2:39 p.m.
Duncan Doyle created JBESB-3772:
-----------------------------------
Summary: 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 CP1, 4.10
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
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 'exception' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:40 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Duncan Doyle updated JBESB-3772:
--------------------------------
Description:
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.
was:
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 'exception' block.
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
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
Labels: esb
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:12 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Sato Tadayoshi updated JBESB-3772:
----------------------------------
Forum Reference: https://community.jboss.org/message/580442
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
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
Labels: esb
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:14 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Sato Tadayoshi updated JBESB-3772:
----------------------------------
Forum Reference: https://community.jboss.org/message/736725 (was:
https://community.jboss.org/message/580442)
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
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
Labels: esb
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:08 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Jason Shepherd commented on JBESB-3772:
---------------------------------------
This should be resolved by the fix for JBESB-3796
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
Labels: esb
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:08 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Jason Shepherd updated JBESB-3772:
----------------------------------
Affects Version/s: 4.11
Forum Reference: https://community.jboss.org/message/736725 (was:
https://community.jboss.org/message/736725)
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
Labels: esb
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:21 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Sato Tadayoshi commented on JBESB-3772:
---------------------------------------
I think this issue and JBESB-3796 are different, because whereas this issue treats the
problem of SyncServiceInvoker prohibiting propagation of ReplyTo/FaultTo to subsequent
actions (i.e. CBRs) and services, JBESB-3796 only treats that the client doesn't
receive a SOAP fault due to removal of ReplyTo/FaultTo from the original request message.
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
Labels: esb
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: http://www.atlassian.com/software/jira
4 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Tom Cunningham reassigned JBESB-3772:
-------------------------------------
Assignee: Sato Tadayoshi
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: Sato Tadayoshi
Labels: esb
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: http://www.atlassian.com/software/jira
11:20 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Tadayoshi Sato <tasato(a)redhat.com> made a comment on [bug
865728|https://bugzilla.redhat.com/show_bug.cgi?id=865728]
Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3772
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.
How reproducible:
Easily by making a reproducer ESB service
Steps to Reproduce:
1. Make a ESB service which invokes SyncServiceInvoker action and a custom action in
order
2. In the second custom action, write a logic which confirms that ReplyTo/FaultTo headers
are erased after the invocation to SyncServiceInvoker
3. Run the ESB service to confirm the reported behaviour
Actual results:
ReplyTo/FaultTo headers are erased
Expected results:
ReplyTo/FaultTo headers should be retained
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: http://www.atlassian.com/software/jira
11:20 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
Tadayoshi Sato resolved JBESB-3772.
-----------------------------------
Fix Version/s: 4.11 CP2
Resolution: Done
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: http://www.atlassian.com/software/jira
11:20 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration updated JBESB-3772:
-------------------------------------------
Bugzilla Update: Perform
Forum Reference: https://community.jboss.org/message/736725 (was:
https://community.jboss.org/message/736725)
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
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: http://www.atlassian.com/software/jira
11:20 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration updated JBESB-3772:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=865728
Forum Reference: https://community.jboss.org/message/736725 (was:
https://community.jboss.org/message/736725)
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
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: http://www.atlassian.com/software/jira
11:22 a.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Tadayoshi Sato <tasato(a)redhat.com> changed the Status of [bug
865728|https://bugzilla.redhat.com/show_bug.cgi?id=865728] from NEW to MODIFIED
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: http://www.atlassian.com/software/jira
5:23 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Julian Coleman <jcoleman(a)redhat.com> changed the Status of [bug
865728|https://bugzilla.redhat.com/show_bug.cgi?id=865728] from MODIFIED to ON_QA
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: http://www.atlassian.com/software/jira
6:16 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration updated JBESB-3772:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=865728,
https://bugzilla.redhat.com/show_bug.cgi?id=876270 (was:
https://bugzilla.redhat.com/show_bug.cgi?id=865728)
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: http://www.atlassian.com/software/jira
6:20 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
876270|https://bugzilla.redhat.com/show_bug.cgi?id=876270]
+++ This bug was initially created as a clone of Bug #865728 +++
Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3772
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.
How reproducible:
Easily by making a reproducer ESB service
Steps to Reproduce:
1. Make a ESB service which invokes SyncServiceInvoker action and a custom action in
order
2. In the second custom action, write a logic which confirms that ReplyTo/FaultTo headers
are erased after the invocation to SyncServiceInvoker
3. Run the ESB service to confirm the reported behaviour
Actual results:
ReplyTo/FaultTo headers are erased
Expected results:
ReplyTo/FaultTo headers should be retained
--- Additional comment from jira-update(a)redhat.com on 2012-10-12 05:19:50 EDT ---
Tadayoshi Sato <tadayosi(a)gmail.com> updated the status of jira JBESB-3772 to
Resolved
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: http://www.atlassian.com/software/jira
6:24 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274]
This BZ is a clone of 865728, which was included in the first SOA-P 5.3 Roll up.
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: http://www.atlassian.com/software/jira
6:24 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274]
+++ This bug was initially created as a clone of Bug #865728 +++
Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3772
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.
How reproducible:
Easily by making a reproducer ESB service
Steps to Reproduce:
1. Make a ESB service which invokes SyncServiceInvoker action and a custom action in
order
2. In the second custom action, write a logic which confirms that ReplyTo/FaultTo headers
are erased after the invocation to SyncServiceInvoker
3. Run the ESB service to confirm the reported behaviour
Actual results:
ReplyTo/FaultTo headers are erased
Expected results:
ReplyTo/FaultTo headers should be retained
--- Additional comment from jira-update(a)redhat.com on 2012-10-12 05:19:50 EDT ---
Tadayoshi Sato <tadayosi(a)gmail.com> updated the status of jira JBESB-3772 to
Resolved
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: http://www.atlassian.com/software/jira
5:36 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Robert Balent <rbalent(a)redhat.com> changed the Status of [bug
865728|https://bugzilla.redhat.com/show_bug.cgi?id=865728] from ON_QA to VERIFIED
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: http://www.atlassian.com/software/jira
7:42 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration updated JBESB-3772:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=865728,
https://bugzilla.redhat.com/show_bug.cgi?id=876270,
https://bugzilla.redhat.com/show_bug.cgi?id=876274 (was:
https://bugzilla.redhat.com/show_bug.cgi?id=865728,
https://bugzilla.redhat.com/show_bug.cgi?id=876270)
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: http://www.atlassian.com/software/jira
7:44 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
865728|https://bugzilla.redhat.com/show_bug.cgi?id=865728] from VERIFIED to CLOSED
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: http://www.atlassian.com/software/jira
8:04 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration updated JBESB-3772:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=865728,
https://bugzilla.redhat.com/show_bug.cgi?id=876270,
https://bugzilla.redhat.com/show_bug.cgi?id=876274,
https://bugzilla.redhat.com/show_bug.cgi?id=881910,
https://bugzilla.redhat.com/show_bug.cgi?id=881919 (was:
https://bugzilla.redhat.com/show_bug.cgi?id=865728,
https://bugzilla.redhat.com/show_bug.cgi?id=876270,
https://bugzilla.redhat.com/show_bug.cgi?id=876274)
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: http://www.atlassian.com/software/jira
8:04 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919]
+++ This bug was initially created as a clone of Bug #876270 +++
+++ This bug was initially created as a clone of Bug #865728 +++
Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3772
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.
How reproducible:
Easily by making a reproducer ESB service
Steps to Reproduce:
1. Make a ESB service which invokes SyncServiceInvoker action and a custom action in
order
2. In the second custom action, write a logic which confirms that ReplyTo/FaultTo headers
are erased after the invocation to SyncServiceInvoker
3. Run the ESB service to confirm the reported behaviour
Actual results:
ReplyTo/FaultTo headers are erased
Expected results:
ReplyTo/FaultTo headers should be retained
--- Additional comment from jira-update(a)redhat.com on 2012-10-12 05:19:50 EDT ---
Tadayoshi Sato <tadayosi(a)gmail.com> updated the status of jira JBESB-3772 to
Resolved
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: http://www.atlassian.com/software/jira
8:06 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
876270|https://bugzilla.redhat.com/show_bug.cgi?id=876270] from NEW to CLOSED
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: http://www.atlassian.com/software/jira
8:14 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274]
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: http://www.atlassian.com/software/jira
8:14 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
881910|https://bugzilla.redhat.com/show_bug.cgi?id=881910] from NEW to CLOSED
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: http://www.atlassian.com/software/jira
8:14 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> made a comment on [bug
881910|https://bugzilla.redhat.com/show_bug.cgi?id=881910]
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: http://www.atlassian.com/software/jira
6:41 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274] from NEW to ASSIGNED
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: http://www.atlassian.com/software/jira
6:41 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919] from NEW to ASSIGNED
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: http://www.atlassian.com/software/jira
6:46 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274] from ASSIGNED to ON_QA
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: http://www.atlassian.com/software/jira
8:03 p.m.
[
https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug
881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919] from ASSIGNED to ON_QA
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: http://www.atlassian.com/software/jira
4167
days inactive
4410
days old
30 comments
6 participants
participants (6)
-
Duncan Doyle (JIRA) -
Jason Shepherd (JIRA)
-
RH Bugzilla Integration (JIRA)
-
Sato Tadayoshi (JIRA)
-
Tadayoshi Sato (JIRA)
-
Tom Cunningham (JIRA)