Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0CB046619 for ; Sun, 5 Jun 2011 12:38:11 +0000 (UTC) Received: (qmail 20820 invoked by uid 500); 5 Jun 2011 12:38:10 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 20778 invoked by uid 500); 5 Jun 2011 12:38:10 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 20766 invoked by uid 99); 5 Jun 2011 12:38:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jun 2011 12:38:10 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jun 2011 12:38:08 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 878D6101589 for ; Sun, 5 Jun 2011 12:37:47 +0000 (UTC) Date: Sun, 5 Jun 2011 12:37:47 +0000 (UTC) From: "Claus Ibsen (JIRA)" To: dev@camel.apache.org Message-ID: <1131092390.69685.1307277467551.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1831981016.48602.1306502928398.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with the xml dsl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044514#comment-13044514 ] Claus Ibsen commented on CAMEL-4022: ------------------------------------ I had a bit time to look into that unit test Hadrian committed. I moved it into its separate unit test file: ExceptionCamel4022Test That makes it easier to debug. I also added a bunch of unit tests that showed the expected behavior of onException when an exception was thrown: ExceptionThrownFromOnExceptionTest The odd thing from Hadrians test is that if you send the message to direct:intermediate instead of direct:start, then it works as expected. I haven't debugged this more throughly to see the oddity. > Issue using errorBuilderRef with the xml dsl > -------------------------------------------- > > Key: CAMEL-4022 > URL: https://issues.apache.org/jira/browse/CAMEL-4022 > Project: Camel > Issue Type: Bug > Affects Versions: 2.7.1 > Reporter: Hadrian Zbarcea > Assignee: Hadrian Zbarcea > Priority: Critical > > While fixing issues around the errorHandler I noticed that definitions defined in the camel context are ignored if a route specifies its own errorHandlerRef. The reason is that we set the onException definition on the default error handler. I have a fix for that, but I discovered a different issue (I think) for which I would like to discuss the solution. > When we have an onException definition that looks kinda like this: > {code} > > java.lang.IllegalArgumentException > > > {code} > ... something happens, the IAE exception is caught, we do something, but in that process another exception is thrown. Currently, that would be caught by the default error handler, which may not be what we want. > What error handler (if any) should handle exceptions thrown while in onException? > The onException mechanism is somewhat similar to a try/catch. I don't think the exceptions thrown while handling onException should be handled by the same error handler configured for the route, or even the context scoped one. The processing should be very simple, predictable and immutable. Since the default "CamelDefaultErrorHandlerBuilder" can be replaced, it is not imho a solution and we need one global one that does as little as possible (the problem would be agreeing what that is: no redeliveries, logging or not, etc). > Thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira