Hi Claus, At the moment we have have a work around which uses a processor instead of a convertBody. In the processor we simply call the convert method. If the processor re-throws the exception that the converter threw then the onException in 1.5.0 works fine.
I will update to the snapshot and see if it works using the converter directly. Is there an estimate of when we may see a 1.5.1? Thanks, Martin ----- Original message ----- From: "Claus Ibsen" <[EMAIL PROTECTED]> To: [email protected] Date: Thu, 4 Dec 2008 14:29:13 +0100 Subject: Re: Handling converter failure Hi Martin I have commited a fix to 2.0 and will merge to 1.5.1 You are welcome to test on your system if it works for you now. /Claus Ibsen Apache Camel Committer Blog: http://davsclaus.blogspot.com/ On Thu, Dec 4, 2008 at 11:16 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote: > Hi Martin > > Yeah the was my initial hunch that RuntimeCamelException was wrapping it. > > Create a JIRA. It's the DefaultExceptionPolicyStrategy that should be > enhanced to check the caused exception as well. Especially if it's a > RuntimeCamelException that is just a wrapper. > > > > /Claus Ibsen > Apache Camel Committer > Blog: http://davsclaus.blogspot.com/ > > > > On Thu, Dec 4, 2008 at 11:09 AM, Martin Gilday <[EMAIL PROTECTED]> wrote: >> Hi Claus, >> >> Exception.class works. So does RuntimeCamelException.class. When you >> look at the log you can see that the IllegalArgumentException is being >> wrapped by the RuntimeCamelException, so the onException handler is >> probably getting given a RCE and not checking the root cause. I will >> create a JIRA. >> >> Thanks, >> Martin >> >> >> ----- Original message ----- >> From: "Claus Ibsen" <[EMAIL PROTECTED]> >> To: [email protected] >> Date: Thu, 4 Dec 2008 10:58:23 +0100 >> Subject: Re: Handling converter failure >> >> Hi >> >> Could you try with onException(Exception.class) just to see if it >> kicks-in then. >> Otherwise we should make sure it catches any exception thrown whatever >> happened during processing of the exchange. >> >> Feel free to create a ticket in JIRA with your unit test so we can try >> to get it fixed in 1.5.1. >> >> >> /Claus Ibsen >> Apache Camel Committer >> Blog: http://davsclaus.blogspot.com/ >> >> >> >> On Thu, Dec 4, 2008 at 10:42 AM, Martin Gilday <[EMAIL PROTECTED]> >> wrote: >>> How do you deal with exceptions thrown by a converter? I have set up >>> some onException clauses but they only seem to kick in if an exception >>> is thrown from a endpoint or a processor. >>> >>> When I run the following code I can see it retrying the default number >>> of times and then the DeadLetterChannel kick in. My mock assertions >>> fail as neither queue recieves any messages. I can see the sysout in >>> the converter being printed, so it is being invoked. >>> Am I doing something incorrect here? I would have thought that there >>> was a strong posibility for a converter to need to throw an exception, >>> in my case here it would be if the message was missing mandatory fields >>> such as telephone number or email. >>> >>> >>> /////Converter >>> @Converter >>> public static LocalDateTime toLocalDateTime(final Object localDateTime) >>> { >>> System.out.println("Converting to local date time"); >>> throw new IllegalArgumentException("Bad data"); >>> } >>> >>> /////Routes >>> Routes routes = new RouteBuilder() { >>> >>> @Override >>> public void configure() throws Exception { >>> >>> onException(IllegalArgumentException.class).handled(true).to("mock:exception"); >>> from("direct:test").convertBodyTo(LocalDateTime.class).to("mock:end"); >>> } >>> }; >>> >>> >>> /////Test >>> MockEndpoint endpoint = (MockEndpoint) >>> camelContext.getEndpoint("mock:end"); >>> endpoint.expectedMessageCount(0); >>> MockEndpoint endpoint2 = (MockEndpoint) >>> camelContext.getEndpoint("mock:exception"); >>> endpoint2.expectedMessageCount(1); >>> >>> camelContext.createProducerTemplate().sendBody("direct:test", "test"); >>> >>> endpoint.assertIsSatisfied(); >>> endpoint2.assertIsSatisfied(); >>> >> >
