[
https://issues.apache.org/activemq/browse/CAMEL-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46301#action_46301
]
davsclaus edited comment on CAMEL-960 at 10/9/08 9:42 PM:
------------------------------------------------------------
Hadrian, yes the unit test is what we want, but I do think that this behavior
should be configurable from
- a new fluent build syntax to indicate its handled.
- a special header on the message to indicate its handled (eg you can do some
java coding in a processor and set that you handled it or not)
- onException should *not* handle it by default (but interesting thought)
- failureHandled fluent syntax also supports a predicate so you can use
So something like a *failureHandled* fluent builder
{code}
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(true)
{code}
Also on the *onException* that I think is a cool feature
{code}
onException(IOException.class).maximumRedeliveries(0).failreHandled(true).to("mock:handled");
{code}
And to let end users do some java coding of their own and set a special header
to indicate handled or not
{code}
onException(IOException.class).maximumRedeliveries(0).process(myFailureHandlerCode);
public class MyFailureHandlerCode implements Processor {
...
public void process(Exchange exchange) throws Exception {
.. // do something
// ah I can handle it so I set this special header
exchange.getIn().setHeader("CamelFailureHandled", true);
}
{code}
And with the predicate for the fluent builder
{code}
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(header("CanIDoIt"))
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(bean(CanIHandleThis.class))
{code}
Also supporting on the onException as well:
{code}
onException(IOException.class).maximumRedeliveries(0).failreHandled(bean(CanIHandleThis.class).to("mock:handled");
{code}
BTW: The fix should be in restoreExceptionOnExchange in DeadLetterChannel.
was (Author: davsclaus):
Hadrian, yes the unit test is what we want, but I do think that this
behavior should be configurable from
- a new fluent build syntax to indicate its handled.
- a special header on the message to indicate its handled (eg you can do some
java coding in a processor and set that you handled it or not)
- onException should *not* handle it by default (but interesting thought)
- failureHandled fluent syntax also supports a predicate so you can use
So something like a *failureHandled* fluent builder
{code}
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(true)
{code}
Also on the *onException* that I think is a cool feature
{code}
onException(IOException.class).maximumRedeliveries(0).failreHandled(true).to("mock:handled");
{code}
And then if possible
onException(IOException.class).maximumRedeliveries(0).process(myFailureHandlerCode);
public class MyFailureHandlerCode implements Processor {
...
public void process(Exchange exchange) throws Exception {
.. // do something
// ah I can handle it so I set this special header
exchange.getIn().setHeader("CamelFailureHandled", true);
}
}
{code}
And with the predicate for the fluent builder
{code}
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(header("CanIDoIt"))
errorHandler(deadLetterChannel().maximumRedeliveries(3).failureHandled(bean(CanIHandleThis.class))
{code}
Also supporting on the onException as well:
{code}
onException(IOException.class).maximumRedeliveries(0).failreHandled(bean(CanIHandleThis.class).to("mock:handled");
{code}
> DeadLetterChannel - option to mark the exchange as failure handled and that
> its OK
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-960
> URL: https://issues.apache.org/activemq/browse/CAMEL-960
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 1.4.0
> Reporter: Claus Ibsen
> Assignee: Hadrian Zbarcea
> Fix For: 1.5.0, 2.0.0
>
>
> Currently the DeadLetterChannel sets the orignal caused exception on the
> exchange *after* it has been failure handled. We should support somekind of
> option to enable/disable this feature. We could support:
> - option on the endpoint to set this for all exchanges
> - support a special header key that end-users can insert per exchange to be
> more dynamic
> - maybe methods on Exchange to set this more easily
> - maybe some refinements in isFailureHandled() to cater for this
> And we should consider use a better keyname in the DLC where it stores the
> original exception.
> See nabble:
> http://www.nabble.com/JMS-%2B-Fault-td19778503s22882.html
> We might need to push this for Camel 2.0 but I think it is a feature that
> end-users would need sooner.
> Any thoughts, please write here?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
