adding logStrackTrace(false) had no effect on my unit test...still works as
expected (tried against 2.10 and against the latest trunk)...

public class RedeliverTest extends ContextTestSupport
{
        
    public void testRedeliver() throws Exception {
        template.sendBody("direct:start", "Hello World");
        getMockEndpoint("mock:b").setExpectedMessageCount(0);
        assertMockEndpointsSatisfied();
    }

    @Override
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            @Override
            public void configure() throws Exception {

                onException(IOException.class)
                    .handled(true)
                    .logStackTrace(false)
                    .maximumRedeliveries(3)
                    .to("log:CONTEXT-ERROR");

                from("direct:start")
                    .onException(IOException.class)
                        //.maximumRedeliveries(3)
                        .logStackTrace(false)
                        .handled(true)
                        .to("log:ROUTE-ERROR")
                        .end()
                    .to("log:TRYING")
                    .process(new MyProcessor())
                    .to("mock:b");
            }
        };
    }

    public static class MyProcessor implements Processor {

        private int counter;

        @Override
        public void process(Exchange exchange) throws Exception {
            System.out.println("trying->" + exchange.getExchangeId());
            if (counter++ < 2) {
                throw new IOException("Forced");
            }
            exchange.getIn().setBody("Bye World");
        }
    }
}


joe82 wrote
> Thanks for reply -
> Ok, so on trying to replicate this myself in a unit test, I discovered the
> exact scenario that causes this...
> If you add the .logStackTrace(true/false) to your onException(...) policy,
> then you will see the context scoped maxRedeliveryAttempts value applied.
> So the below route-scoped exception policy is picking up the
> context-scoped error policy redelivery value (defined as 3):
> 
> from("direct:testscope")
>                 .onException(Exception.class)
>                     .handled(true)
>                     .logStackTrace(false)
>                     .to("mock:exception")
>                 .end()
> 
> But omitting the .logStackTrace(..) like below, picks up the expected
> default redelivery attempts of 0.
> 
> from("direct:testscope")
>                 .onException(Exception.class)
>                     .handled(true)
>                     .to("mock:exception")
>                 .end()
> 
> Do you find same if you add this to your route policy?
> 
> Regards,
> joanne
> 
> 
> From: boday [via Camel] [mailto:

> ml-node+s465427n5727441h63@.nabble

> ]
> Sent: 12 February 2013 16:51
> To: Gilmore, Joanne
> Subject: Re: default maximum redelivery policy when overridding default
> error handler not right
> 
> I just created a basic test and it seemed to work fine for my scenario. 
> Can you attach a unit test that replicates this?
> joe82 wrote
> According the the camel documentation, if you provide a context-scoped
> error handling policy, and then a route-scoped onException policy also -
> the MaximumRedeliveries for the route-scoped policy should default to 0
> regardless of whether or not your context-scoped error handling policy had
> overwitten it.
> This does not appear to be correct, as I have found in this scenario, the
> MaximumRedeliveries default on my route-scoped onException policy was
> picking up the value which I had defined in the context-scoped error
> handling policy which was 3, instead of what I expected it to be (0).
> So I had to explicitly set the MaximumRedeliveries on the route-scoped
> policy to be 0.
> The version of camel for this project is 2.10.2.
> 
> Has anyone noticed this? has it been raised with camel?
> Ben O'Day
> IT Consultant -http://consulting-notes.com
> 
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://camel.465427.n5.nabble.com/default-maximum-redelivery-policy-when-overridding-default-error-handler-not-right-tp5727230p5727441.html
> To unsubscribe from default maximum redelivery policy when overridding
> default error handler not right, click
> here&lt;http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&amp;node=5727230&amp;code=am9hbm5lLmdpbG1vcmVAZm1yLmNvbXw1NzI3MjMwfDEwOTU3ODMyMzY=&gt;.
> NAML&lt;http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&amp;id=instant_html%21nabble%3Aemail.naml&amp;base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&amp;breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml&gt;





-----
Ben O'Day
IT Consultant -http://consulting-notes.com

--
View this message in context: 
http://camel.465427.n5.nabble.com/default-maximum-redelivery-policy-when-overridding-default-error-handler-not-right-tp5727230p5727529.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to