The current ServiceExceptionStrategy-implementation (generated at the bottom of
flows):
<custom-exception-strategy class="org.soitoolkit.commons.mule.error.ServiceExceptionStrategy"/>
lacks features:
1. Control over retry-handling: for which kind of exceptions should processing
be retried/aborted?
Note: retry-handling currently falls back on individual transports, typically
using JMS-inbound with retry-parameters.
2. Access to MuleMessage when exceptions occur: needed for logging
error-context like message-headers, specifically correlationId for a flow.
Note: in current ServiceExceptionStrategy the MuleMessage is not available in
all cases, like when a TransformerException occurs.
Original issue reported on code.google.com by hakan.d...@gmail.com on 9 Nov 2013 at 9:17
Original issue reported on code.google.com by
hakan.d...@gmail.com
on 9 Nov 2013 at 9:17