Bug 779159 - (SOA-1554) Schema Validation - Routing to configured action is not supported
Schema Validation - Routing to configured action is not supported
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.0.0 ER1
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Burr Sutter
Depends On:
  Show dependency treegraph
Reported: 2009-10-26 06:34 EDT by Jiri Pechanec
Modified: 2009-12-02 05:18 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-02 05:18:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-1554 Critical Closed Schema Validation - Routing to configured action is not supported 2013-01-29 14:16:28 EST

  None (edit)
Description Jiri Pechanec 2009-10-26 06:34:39 EDT
Date of First Response: 2009-10-26 06:39:52
project_key: SOA

From PRD:
Validation errors will be explicitly logged in the ESB log file and the action will have a parameter that determines what ESB service to route to in the case of errors.

The current implementation merely encapsulate and rethrow the exception which means that
1) Either DLS or redelivery service will be used based on sync/async delivery
2) It is not possible to setup custom target service

ERD reference4.1.22 Schema Validation
 Priority:                                        Status:
                    High                                      Committed
 Responsible team:                                Originator:
                    JBoss ESB                                 Engineering
 Requirement:       Action for Schema validation.
Comment 1 Kevin Conner 2009-10-26 06:39:52 EDT
Validation errors are treated in the same manner as any other exception, there is no special handling.

The description in the PRD does not make sense within the context of the pipeline.
Comment 2 Kevin Conner 2009-10-26 10:46:24 EDT
We committed to implementing the schema validation in line with the processing expected in the pipeline, this has been done.

As stated earlier, the description in the PRD makes no sense within the context of the pipeline.
Comment 3 Jiri Pechanec 2009-10-27 05:59:36 EDT
Please review the issues and create change requests if you feel the issues are valid, otherwise resolve them as rejected
Comment 4 Burr Sutter 2009-10-30 16:53:10 EDT
The current programmers guide entry (in ESB trunk) for 
does not indicate what happens in case their is a validation error.  

Does this section from the programmers guide describe it accurately?
When processing an action chain, it is possible that errors may occur. Such errors should be thrown as exceptions from the Action pipeline, thus terminating the processing of the pipeline. As mentioned earlier, a Fault Message may be returned within an ActionProcessingFaultException. If it is important for information about errors to be returned to the sender (or some intermediary) then the FaultTo EPR should be set. If this is not set, then JBossESB will attempt to deliver error messages based on the ReplyTo EPR and, if that is also not set, the From EPR. If none of these EPRs has been set, then error information will be logged locally.
Error messages of various types can be returned from the Action implementations. However, JBossESB supports the following "system" error messages, all of which may be identified by the mentioned URI in the message Fault, in the case that an exception is thrown and no application specific Fault Message is present:
urn:action/error/actionprocessingerror: this means that an action in the chain threw an ActionProcessingFaultException but did not include a fault message to return. The exception details will be contained within the "reason" String of the Fault.
urn:action/error/unexpectederror: an unexpected exception was caught during the processing. Details about the exception can be found in the "reason" String of the Fault.
urn:action/error/disabled: action processing is disabled.
If an exception is thrown within your Action chain, then it will be propagated back to the client within a FaultMessageException, which is re-thrown from the Courier or ServiceInvoker classes. This exception, which is also thrown whenever a Fault message is received, will contain the Fault code and reason, as well as any propagated exception.
To be clear our users want to be able to route errors to a particular location/service/log so they can easily see that their errors (be alerted to them in some cases) and then have a copy of the message that caused the problem, even updating the message and "replaying" it.
Comment 5 Kevin Conner 2009-11-02 05:19:54 EST
Yes, the behaviour is the same for all failures.

We do not have any mechanism to allow modification/replaying of their messages though, so they would have to handle this themselves.
Comment 6 trev 2009-12-02 05:18:12 EST
Exceptions are handled through the standard mechanism

Note You need to log in before you can comment on or make changes to this bug.