You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Hadrian Zbarcea (JIRA)" <ji...@apache.org> on 2011/05/27 15:28:48 UTC
[jira] [Created] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
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
While fixing issues around the errorHandler I noticed that <onException> 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}
<onException>
<exception> java.lang.IllegalArgumentException</exception>
<to uri="mock:illegalArgumentException"/>
</onException>
{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?
[I will get back later today with the options I see, but comments are appreciated in the meantime]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042896#comment-13042896 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
Johan, not sure how edge-case it is. Absolutely agree that we should not just swallow it.
Actually since it's a separate issue than the one reported here, I opened an improvement issue CAMEL-4041, and we can continue the discussion there.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Resolved] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-4022.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.8.0
Fixed by CAMEL-4041. I added better validation of OnException so you cannot mis configure it.
> 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: Claus Ibsen
> Priority: Critical
> Fix For: 2.8.0
>
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Updated] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea updated CAMEL-4022:
-----------------------------------
Priority: Critical (was: Major)
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040250#comment-13040250 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
To be more precise, I believe exceptions thrown while handling are extremely exceptional and imho indicate a design/coding problem that needs to be resolved by the developer and should not appear in production. I don't see any good choice a framework like camel can make for you in such situations.
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Assigned] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-4022:
----------------------------------
Assignee: Claus Ibsen (was: Hadrian Zbarcea)
> 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: Claus Ibsen
> Priority: Critical
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044520#comment-13044520 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
The current logic for onException is as follows:
1. onException will shadow any errorHandler
2. any errorHandler does not take part if onException is processing an exception (this is the intend, but Hadrian created an unit test where the DLC interfered)
The logic in onException is roughly a "magic" try .. catch
{code}
try
// while loop routing the exchange
} catch (OnException e) {
try {
// onException route logic goes here, if there is any
} catch (Throwable t) {
// ops an exception occurred in onException, we will store it on the exchange
// TOOD: this is where we may want the onExceptionErrorHandler (to log the exception or something)
exchange.setException(t);
}
if (!continued) {
// mark exchange to stop routing (this is the default behavior)
}
if (!handled) {
// if onException is configured to NOT handle, then rethrown exception (this is the default behavior)
throw exchange.getException();
}
}
{code}
So if an exception is thrown during onException processing, then that exception is caught. But we may want to introduce that OnExceptionErrorHandler (FatalErrorHandler as named by Hadrian) to log the exception (I think that's already done). But having an OnExceptionErrorHandler, we could let end user configure what to do. But again this may just become more complicated.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045245#comment-13045245 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
@Claus, I agree a full test is absolutely necessary before committing.
FWIW, I know this ErrorHandler is only used with OnException, i.e. when onException is used in the DSL. Naming the handler OnExceptionErrorHandler will therefore relate to the route building syntax, not the semantics which to me is a problem. I trust you'll be able to come with something better.
Couple of comments on the patch: the error handler could be a singleton (obviously stateless). I think logging should be at error level. To your comment in the code, I don't think anything related to this error handler should be configurable.
That said, it's definitely a step in the right direction. Feel free to commit the patch. We can follow up with more changes once we agree on the other details and then close the issue (CAMEL-4041).
> 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
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Issue Comment Edited] (CAMEL-4022) Issue using
errorBuilderRef with the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040237#comment-13040237 ]
Claus Ibsen edited comment on CAMEL-4022 at 5/27/11 1:56 PM:
-------------------------------------------------------------
The behavior should be that no error handler should be used, when routing inside the <onException>.
For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.
The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).
If you want to continue routing and have error handling, then send the message to a route:
onException(SomeException.class).handled(true).to("direct:someRoute");
was (Author: davsclaus):
The behavior should be that no error handler should be used, when routing inside the <onException>.
For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.
The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).
If you want to continue routing and have error handling, then send the message to a route:
onException(x).handled(true).to("direct:someRoute");
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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?
> [I will get back later today with the options I see, but comments are appreciated in the meantime]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Edstrom Johan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042852#comment-13042852 ]
Edstrom Johan commented on CAMEL-4022:
--------------------------------------
This is an interesting use-case....
I strongly agree that it is an edge-case, ideally I think this should be something that is done as try/catch/finally, but since the case can occur
from my looking at the test I agree that some sort of fatalError is at least a good start.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044551#comment-13044551 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
Okay Hadrian is correct when he suggests a OnExceptionErrorHandler (he named it FatalErrorHandler) that is stateless and doesn't do redelivery and whatnot. I got a prototype up and running with that now.
So what we need to consider is what the outcome of the processing of the Exchange should be when using OnException and a 2nd exception is thrown from within OnException. I hope you follow me now.
As I see we can do either of the following
a) log the 2nd exception and then ignore it
b) log the 2nd exception and set it as exception on the Exchange
c) as b + force the exchange to fail, even if continued/handled was set to true
d) as b + having an option to control if we should force the exchange to fail or not
And in terms of logging, we can have log level options end users can control in case they don't want that. But by default I suggest its logged at WARN level incl. stacktraces
The "big" questions is what we should consider as the outcome. Should the 2nd exception be ignored or not. And if not ignored should it replace the 1st exception on the Exchange. And if so should we always force the Exchange to fail, even if the end user configured handled(true) etc.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040237#comment-13040237 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
The behavior should be that no error handler should be used, when routing inside the <onException>.
For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.
The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).
If you want to continue routing and have error handling, then send the message to a route:
onException(x).handled(true).to("direct:someRoute");
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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?
> [I will get back later today with the options I see, but comments are appreciated in the meantime]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Edstrom Johan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042856#comment-13042856 ]
Edstrom Johan commented on CAMEL-4022:
--------------------------------------
Second comment, whatever we do, I think the most important is that it is not hidden from the user in any way shape or form.
Like swallowing it and carrying on as if nothing happened...
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Updated] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea updated CAMEL-4022:
-----------------------------------
Description:
While fixing issues around the errorHandler I noticed that <onException> 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}
<onException>
<exception> java.lang.IllegalArgumentException</exception>
<to uri="mock:illegalArgumentException"/>
</onException>
{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?
was:
While fixing issues around the errorHandler I noticed that <onException> 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}
<onException>
<exception> java.lang.IllegalArgumentException</exception>
<to uri="mock:illegalArgumentException"/>
</onException>
{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?
[I will get back later today with the options I see, but comments are appreciated in the meantime]
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044899#comment-13044899 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
Hadrian fell free to look at the attached patch file, it goes most of the stuff in place. Of course some unit tests have to be adjusted slightly as they was dependent on the old code. Likewise there may be some tests in camel-spring that need to be adjusted.
Since this would be a bigger change, a good idea is to run a full test before committing :)
> 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
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040246#comment-13040246 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
@Claus, thanks for the input. That's the issue, what if I don't want handled(true) and to("direct:someRoute") fails?
For the situation you mention where there is an onException handling the exception thrown while handling, that should *not* trigger. That is only meant for exceptions thrown on the route, not while handling. I believe exception thrown while handling have a special status and should be handled differently, in a simple, predictable way, not by the ErrorHandler configured for the route.
We need to come up with a good convention.
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044764#comment-13044764 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
I have added unit tests on trunk
http://svn.apache.org/viewvc?rev=1132562&view=rev
That tests for <onException> with both context and route scoped error handlers. I cannot reproduce the issue Hadrian reported in the initial comment of this JIRA ticket.
The test Hadrian created in r1130232 does neither reproduce it as its only a Java DSL test (no XML DSL test as well) and it indicated another issue, which is what should happen if another exception is thrown during processing onException. That is ticket CAMEL-4041.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046542#comment-13046542 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
Okay I will return to this ticket and the patch, now that I got time again.
> 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
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Updated] (CAMEL-4022) Issue using errorBuilderRef with the
xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-4022:
-------------------------------
Attachment: onexceptionerrorhandler.patch
Work in progress patch for this new error handler.
> 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
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Issue Comment Edited] (CAMEL-4022) Issue using
errorBuilderRef with the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040237#comment-13040237 ]
Claus Ibsen edited comment on CAMEL-4022 at 5/27/11 1:56 PM:
-------------------------------------------------------------
The behavior should be that no error handler should be used, when routing inside the <onException>.
For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.
The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).
If you want to continue routing and have error handling, then send the message to a route:
{code}
onException(SomeException.class).handled(true).to("direct:someRoute");
{code}
was (Author: davsclaus):
The behavior should be that no error handler should be used, when routing inside the <onException>.
For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.
The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).
If you want to continue routing and have error handling, then send the message to a route:
onException(SomeException.class).handled(true).to("direct:someRoute");
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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?
> [I will get back later today with the options I see, but comments are appreciated in the meantime]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CAMEL-4022) Issue using
errorBuilderRef with the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044551#comment-13044551 ]
Claus Ibsen edited comment on CAMEL-4022 at 6/6/11 9:48 AM:
------------------------------------------------------------
*Note:* We ought to discuss this in ticket CAMEL-4041
Okay Hadrian is correct when he suggests a OnExceptionErrorHandler (he named it FatalErrorHandler) that is stateless and doesn't do redelivery and whatnot. I got a prototype up and running with that now.
So what we need to consider is what the outcome of the processing of the Exchange should be when using OnException and a 2nd exception is thrown from within OnException. I hope you follow me now.
As I see we can do either of the following
a) log the 2nd exception and then ignore it
b) log the 2nd exception and set it as exception on the Exchange
c) as b + force the exchange to fail, even if continued/handled was set to true
d) as b + having an option to control if we should force the exchange to fail or not
And in terms of logging, we can have log level options end users can control in case they don't want that. But by default I suggest its logged at WARN level incl. stacktraces
The "big" questions is what we should consider as the outcome. Should the 2nd exception be ignored or not. And if not ignored should it replace the 1st exception on the Exchange. And if so should we always force the Exchange to fail, even if the end user configured handled(true) etc.
was (Author: davsclaus):
Okay Hadrian is correct when he suggests a OnExceptionErrorHandler (he named it FatalErrorHandler) that is stateless and doesn't do redelivery and whatnot. I got a prototype up and running with that now.
So what we need to consider is what the outcome of the processing of the Exchange should be when using OnException and a 2nd exception is thrown from within OnException. I hope you follow me now.
As I see we can do either of the following
a) log the 2nd exception and then ignore it
b) log the 2nd exception and set it as exception on the Exchange
c) as b + force the exchange to fail, even if continued/handled was set to true
d) as b + having an option to control if we should force the exchange to fail or not
And in terms of logging, we can have log level options end users can control in case they don't want that. But by default I suggest its logged at WARN level incl. stacktraces
The "big" questions is what we should consider as the outcome. Should the 2nd exception be ignored or not. And if not ignored should it replace the 1st exception on the Exchange. And if so should we always force the Exchange to fail, even if the end user configured handled(true) etc.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042306#comment-13042306 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
I added a test in r1130232 that demonstrates the problem. What should happen if exception is thrown while handling exception? Imho, certainly not going through redeliveries and the default error handler (which can be replaced by the user app).
Thoughts?
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044886#comment-13044886 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
And in terms of the options listed. I also currently agree/think that *c* is the best and what the end user would expect. The exception is not hidden etc. It causes the exchange to fail. And its being logged so they can find it in the log also.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046634#comment-13046634 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
Will take a bit more work to get the XML DSL side working as they use error handler ref, and this indirection takes a bit more work to proper setup with this new FatalErrorHandler.
> 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: Claus Ibsen
> Priority: Critical
> Attachments: onexceptionerrorhandler.patch
>
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Issue Comment Edited] (CAMEL-4022) Issue using
errorBuilderRef with the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042306#comment-13042306 ]
Hadrian Zbarcea edited comment on CAMEL-4022 at 6/1/11 5:39 PM:
----------------------------------------------------------------
I added a test in r1130232 that demonstrates the problem. What should happen if exception is thrown while handling exception? Imho, certainly not going through redeliveries and the default error handler (which can be replaced by the user app).
My proposal is to have a fatalErrorHandler for this scenario that is simple and stateless (i.e. no redelivery and virtually no chances of throwing other exceptions, no sending to other endpoints). If that sounds good I can implement the piping for it while we keep discussing what exactly the fatalErrorHandler should do. If you can think of better solutions feel free to comment.
Thoughts?
was (Author: hadrian):
I added a test in r1130232 that demonstrates the problem. What should happen if exception is thrown while handling exception? Imho, certainly not going through redeliveries and the default error handler (which can be replaced by the user app).
Thoughts?
> 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
>
> While fixing issues around the errorHandler I noticed that <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044883#comment-13044883 ]
Claus Ibsen commented on CAMEL-4022:
------------------------------------
> To the not very important issue of naming, I think OnExceptionErrorHandler is much less descriptive than FatalErrorHandler, which may not be the best name either. More descriptive would be ExceptionWhileHandlingExceptionErrorHandler, which to me sounded like Fatal.
??? That new error handler is *only* being used when you use OnException, and thus a description that indicate that is much better than a general/confusing name such as FatalErrorHandler. The name ExceptionWhileHandlingExceptionErrorHandler is a better description but again it doesn't trigger/being used, in case, lets say DeadLetterChannel itself caused a fatal exception while processing the exception.
So having the name OnExceptionErrorHandler is a better description as it points the user/reader in the direction its being used when you use OnException.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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
[jira] [Commented] (CAMEL-4022) Issue using errorBuilderRef with
the xml dsl
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044876#comment-13044876 ]
Hadrian Zbarcea commented on CAMEL-4022:
----------------------------------------
Claus, I can understand how you got confused. I should have been clearer in the description above. This shouldn't be a duplicate of CAMEL-3989, as I said in the description above: "I discovered a different issue". And the problem, although I discovered while looking into the camel-spring issue is in camel-core. Anyway, the title and description are not clear, I agree with that.
Regarding your comment above, yes, my test targeted the java dsl, to resolve the part of the issue that became CAMEL-4041 on Thu, one day later.
I don't think it's worth getting pedantic and cleanup the description and title of this issue (feel free if you think it's important). I would however continue the discussion for CAMEL-4041 here, because we have the context here (unless we copy a couple of the relevant comments there).
To the not very important issue of naming, I think OnExceptionErrorHandler is much less descriptive than FatalErrorHandler, which may not be the best name either. More descriptive would be ExceptionWhileHandlingExceptionErrorHandler, which to me sounded like Fatal.
To the proposed issues of having it configurable, I am strongly against it being configurable. This is a fatal situation that should not occur in the first place. If the exception should be ignored, again no, I believe Johan said the same thing. This is a situation much more likely to appear during development (in production it would be only the result of insufficient testing). We should fail fast and loud. So the only viable solution to me is c), something like an 'internal server error'. There are other solutions to be considered, like stopping the route, but given the stateless nature of camel routes I don't think we should go that far.
> 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 <onException> 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}
> <onException>
> <exception> java.lang.IllegalArgumentException</exception>
> <to uri="mock:illegalArgumentException"/>
> </onException>
> {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