Red Hat Bugzilla – Bug 779159
Schema Validation - Routing to configured action is not supported
Last modified: 2009-12-02 05:18:12 EST
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. Comments: Attachments: Interdependencies:
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.
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.
Please review the issues and create change requests if you feel the issues are valid, otherwise resolve them as rejected
The current programmers guide entry (in ESB trunk) for org.jboss.soa.esb.actions.validation.SchemaValidationAction 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.
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.
Exceptions are handled through the standard mechanism