[
http://jira.jboss.com/jira/browse/JBESB-193?page=comments#action_12360833 ]
Mark Little commented on JBESB-193:
-----------------------------------
Have been working on the following changes to the chaining.
If a message comes back from process and it has a Fault defined, then the processing stops
and the message will be sent back (it's an error message).
If an error happens at any point in the chaining and/or results in an exception, then a
specific error message will be sent back (it will have a Fault defined).
The destination of these error messages will be based on:
(i) FaultTo on original message
(ii) if no FaultTo set, then ReplyTo on original message
(iii) if no ReplyTo, then From on original message.
(iv) if no From then default ReplyTo should have been set at the sender anyway.
Any message returned from process can have its own Call section in the message. In which
case, a Fault message returned will be routed giving preference to that information over
anything that came in on the original received message.
Need support for notification generatoin from within
ActionProcessor.process method
-----------------------------------------------------------------------------------
Key: JBESB-193
URL:
http://jira.jboss.com/jira/browse/JBESB-193
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 5.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Fix For: 4.2
In version 4.0, the Action Processing pipeline management code raises notifications in
response to an exception from the ActionProcessor.process method. The pipeline managemnt
code calls the getOkNotification (no exception) or getErrorNotification (exception) to get
the notification message.
For many reasons, this is a very flawed model. Notifications should be raised from
within the process method by means of attaching the notifications (error or otherwise) to
the message (the mechanism is a design issue). Once the process method returns, the
pipline processing management code can check the message for notifications. If there are
errors, it can/should (?) abort the message processing, send the error notification (by
whatever notification options are configured on the listener) and signal the failure to
the calling process (by whatever failure config is configured on the listener).
The getOk and getErro methods can then be removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira