Mule

Created separate issue on properly configuration of request-response, which will better serve a solution for error handling.

Ross,

Although it is fairly trivial to return error feedback in general I believe the example should demonstrate this with as much configuration and existing core implementations as possible. I presume that error handling implies exception handling in your issue request. AFAIK, errors can only occur on either connector or component. I further believe what we want is simply telling the user that either no name or a bad name was provided.

[How errors can occur]
#1 Connector errors

• Connection fails or breaks on endpoint, e.g. unplugged cable.
• Transformer fails. The current hello example will fail with HttpRequestToString if the url looks something like http://localhost:8888.

#2 Component errors

• Business logic error. There's currently nothing that can break but we could put something in place, e.g. name must be specified and start with capital letters.

[Ways to address errors]
Based on the above I was trying out a couple of implementations with different levels of success:

#1 Use <exception-strategy> on connector and component
This initially was my first choice and IMO the most straight-forward configuration using the DefaultExceptionStrategy combined with an vm://errorHandler endpoint and responseTransformer specified. Unfortunately, I didn't find a way to return any response via http using this mechanism. The responseTransformer attribute didn't work the same way as it nicely does on a valid endpoint. Looking at the DefaultExceptionStrategy implementation I believe that error messaging is not part of the original message flow and therefore can't return anything. I really was hoping this is the way to go, but apparently it only works one way if you e.g. want to store errors on the file system or route them elsewhere. Unless I am missing anything, shall I file an enhancement request?

#2 Handle errors in components through custom exception implementation returning feedback as regular response message once exception was handled.
Such an implementation requires addtl. custom implementation in components and IMO does not demonstrate error handling very well. Certainly, it would describe the one way to do it, but I don't think it adds extra value to the current hello example. It already demonstrates how to respond via http at all. In addition, this error handling wouldn't cover the HttpRequestToString transformer failure when no name parameter is provided and hence had to be taken care separately within the HttpRequestToString implementation.

Although I wanted to demonstrate error handling using exceptions strategies it seems as if #2 is the way to go.

Did you have anything else in mind, more fancy or maybe even simpler?

-Andreas

[First part]
Prepare codebase for error handling by moving endpoint specific implementations from components and canonical object NameString into endpoint specific transformers. Also removed payload error handling from transformers, which in a subsequent commit will be implemented into component. I tested against all hello configurations, including webapp module.'

r8009

Follow-up on previous change based on Andrew P's comments. Removed instanceof and added setReturnType on transformers where only a single type is expected.

r8015

r8022

Implemented error handling as follows:

1. User errors when invalid name is provided:
   A message is returned to user asking to provide proper name. I implemented this using a filtered outbound router. An Exception object, here for demonstration purpose, matches the vm://userErrorHandler and returns the message.

1. System errors when e.g. a component exception occurs
   Errors are logged through exception-strategy mechanism.

Error handling is implemented independently from transport used. Hence, it works for http, stdin, and rest approach. I haven't updated the spring configuration but don't think this is necessary to do to demonstrate how error handling could potentially be configured.

I tested all transports through ./hello script and webapp on http://localhost:8090/mule-examples.

There are a few commits that need to go into 1.4

r8023.

I spoke with Ross and he has some good suggestions on improving parts of my work. Hence, reopened the issue for these improvements:

Ross "... Can you add a little more documentation to the ErrorHandler components to say that "these don't do any thing but you can add additional routing logic - or something like that so that people understand why they are there but don't do anything. Aslo, use the BridgeComponent rather than pass through. And since System errors don't go anywhere maybe write them to System.err"

I added Ross suggestions with r8066.

r8067.