[
https://issues.apache.org/activemq/browse/CAMEL-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46300#action_46300 ]
hadrian edited comment on CAMEL-960 at 10/9/08 9:25 PM:
----------------------------------------------------------------
I think I can get this fixed pretty quickly, but I am not sure I understand the issue well. There is fairly good set of tests in ExceptionBuilderTest.java. From what I understand your point is that if one specifies something like:
{code}
onException(IOException.class).maximumRedeliveries(0).to("mock:handled");
from("direct:a").to("mock:result");
{code}
then the following code (which works today) is *wrong*:
{code}
try {
template.sendBody("direct:a", "Hello world");
fail("Should have thrown a MyBusinessException");
} catch (RuntimeCamelException e) {
assertTrue(e.getCause() instanceof MyBusinessException);
// expected
}
{code}
and RuntimeCamelException should *not* be thrown because the exception was actually handled in a satisfactory way. The test should only have:
{code}
MockEndpoint result = getMockEndpoint("mock:result");
result.expectedMessageCount(0);
MockEndpoint handled = getMockEndpoint("mock:handled");
handled.expectedMessageCount(1);
template.sendBody("direct:a", "Hello world");
// no exception, mock:result does not get a message, mock: handled gets one, no redelivery attempts
result.assertIsSatisfied();
handled.assertIsSatisfied();
{code}
For other exceptions that are not specified in an onException statement, or if onException only modifies the redelivery policy, the behavior should stay the same, and the RuntimeCamelException is to be expected.
Is my understanding correct?
was (Author: hadrian):
I think I can get this fixed pretty quickly, but I am not sure I understand the issue well. There is fairly good set of tests in ExceptionBuilderTest.java. From what I understand your point is that if one specifies something like:
{code}
onException(IOException.class)..maximumRedeliveries(0).to("mock:handled");
from("direct:a").to("mock:result");
{code}
then the following code (which works today) is *wrong*:
{code}
try {
template.sendBody("direct:a", "Hello world");
fail("Should have thrown a MyBusinessException");
} catch (RuntimeCamelException e) {
assertTrue(e.getCause() instanceof MyBusinessException);
// expected
}
{code}
and RuntimeCamelException should *not* be thrown because the exception was actually handled in a satisfactory way. The test should only have:
{code}
MockEndpoint result = getMockEndpoint("mock:result");
result.expectedMessageCount(0);
MockEndpoint handled = getMockEndpoint("mock:handled");
handled.expectedMessageCount(1);
template.sendBody("direct:a", "Hello world");
// no exception, mock:result does not get a message, mock: handled gets one, no redelivery attempts
result.assertIsSatisfied();
handled.assertIsSatisfied();
{code}
For other exceptions that are not specified in an onException statement, or if onException only modifies the redelivery policy, the behavior should stay the same, and the RuntimeCamelException is to be expected.
Is my understanding correct?
> 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.
