Exception handling ... onException

[DRy]

Hi,

if I use two onException expressions in a route definition like this

        onException(UnmarshalException.class)
            .useOriginalBody()
            .handled(true)
                .bean(exceptionLogBean)
                .process(new Publish2CenterExceptionBean())
            .end();
       
        onException(Exception.class)
            .maximumRedeliveries(-1).redeliveryDelay(1000)
            .useOriginalBody()
            .handled(true)
                .bean(exceptionLogBean)
            .rollback()
            .end();

I got two problems:

1)
The onEception(Exception.class) part is used all the time! Even if an UnmarshalException (direct hit) is thrown. And no matter if I put onException(Exception.class)... before onException(UnmarshalException.class)... ... ?

2)
On the onException(Exception.class) part the bean(exceptionLogBean) is never called ... ?

What I try to do is, to handle all "known" exception in seperate onException(...) parts and install a "last line of defence" with the onException(Exception.class).


DRy

[Claus Ibsen-2]

Hi

What version of Camel are you using?

And do you use global or route scoped onException ?



On Thu, Nov 5, 2009 at 3:28 PM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
> if I use two onException expressions in a route definition like this
>
>        onException(UnmarshalException.class)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>                .process(new Publish2CenterExceptionBean())
>            .end();
>
>        onException(Exception.class)
>            .maximumRedeliveries(-1).redeliveryDelay(1000)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>            .rollback()
>            .end();
>
> I got two problems:
>
> 1)
> The onEception(Exception.class) part is used all the time! Even if an
> UnmarshalException (direct hit) is thrown. And no matter if I put
> onException(Exception.class)... before
> onException(UnmarshalException.class)... ... ?
>
> 2)
> On the onException(Exception.class) part the bean(exceptionLogBean) is never
> called ... ?
>
> What I try to do is, to handle all "known" exception in seperate
> onException(...) parts and install a "last line of defence" with the
> onException(Exception.class).
>
>
> DRy
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26215607.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[DRy ()]

Hi,

we used one of the latest 2.1 snapshots (2009-11-02). Today I tried the 2009-11-06 2.1 snapshot - same problem.

We use the onException-expressions (from the example below) in a RouteBuilder-class with one defined route. Both onException are placed before the route definition. So far the scope is global.


DRy

Claus Ibsen-2 wrote:

What version of Camel are you using?

And do you use global or route scoped onException ?

On Thu, Nov 5, 2009 at 3:28 PM, DRy <[e-mail]> wrote:
>
> Hi,
>
> if I use two onException expressions in a route definition like this
>
>        onException(UnmarshalException.class)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>                .process(new Publish2CenterExceptionBean())
>            .end();
>
>        onException(Exception.class)
>            .maximumRedeliveries(-1).redeliveryDelay(1000)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>            .rollback()
>            .end();
>
> I got two problems:
>
> 1)
> The onEception(Exception.class) part is used all the time! Even if an
> UnmarshalException (direct hit) is thrown. And no matter if I put
> onException(Exception.class)... before
> onException(UnmarshalException.class)... ... ?
>
> 2)
> On the onException(Exception.class) part the bean(exceptionLogBean) is never
> called ... ?
>
> What I try to do is, to handle all "known" exception in seperate
> onException(...) parts and install a "last line of defence" with the
> onException(Exception.class).
>
>
> DRy

[DRy ()]

Hi,

if I replace Exception.class with IOException (for example) it works fine for these two types of exception then!

>        onException(UnmarshalException.class)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>                .process(new Publish2CenterExceptionBean())
>            .end();
>
>        onException(IOException.class)
>            .maximumRedeliveries(-1).redeliveryDelay(1000)
>            .useOriginalBody()
>            .handled(true)
>                .bean(exceptionLogBean)
>            .rollback()

Any ideas so far ... ?


There is another problem within this:

If there is a another (a new) exception within any onException-part, the message is lost. Even in an onException where maximumRedeliveries(-1) is set (like in onException(IOException.class) in my example)!


... DRy

[Christian Schneider]

Hi,

I have also woked with the onException clause recently and it worked for
me. I used the spring dsl though.
It surely would help if you can create a small example project that
shows your problem and post it for example
to a jira ticket. Once there is some code that can be debugged it is
ususally quite easy to find a solution.

Greetings

Christian


DRy schrieb:

> Hi,
>
> we use one of the latest 2.1 snapshots (I will have a look at the exact date
> tomorrow).
>
> We use the onException-expressions (from the example below) in a
> RouteBuilder-class with one defined route. Both onException are placed
> before the route definition. So far the scope is global.
>
>
> DRy
>
>
> Claus Ibsen-2 wrote:
>  
>> What version of Camel are you using?
>>
>> And do you use global or route scoped onException ?
>>
>> On Thu, Nov 5, 2009 at 3:28 PM, DRy <dirk.rybinski@...> wrote:
>>    
>>> Hi,
>>>
>>> if I use two onException expressions in a route definition like this
>>>
>>>        onException(UnmarshalException.class)
>>>            .useOriginalBody()
>>>            .handled(true)
>>>                .bean(exceptionLogBean)
>>>                .process(new Publish2CenterExceptionBean())
>>>            .end();
>>>
>>>        onException(Exception.class)
>>>            .maximumRedeliveries(-1).redeliveryDelay(1000)
>>>            .useOriginalBody()
>>>            .handled(true)
>>>                .bean(exceptionLogBean)
>>>            .rollback()
>>>            .end();
>>>
>>> I got two problems:
>>>
>>> 1)
>>> The onEception(Exception.class) part is used all the time! Even if an
>>> UnmarshalException (direct hit) is thrown. And no matter if I put
>>> onException(Exception.class)... before
>>> onException(UnmarshalException.class)... ... ?
>>>
>>> 2)
>>> On the onException(Exception.class) part the bean(exceptionLogBean) is
>>> never
>>> called ... ?
>>>
>>> What I try to do is, to handle all "known" exception in seperate
>>> onException(...) parts and install a "last line of defence" with the
>>> onException(Exception.class).
>>>
>>>
>>> DRy
>>>      
>
>  

[Claus Ibsen-2]

On Sat, Nov 7, 2009 at 8:11 AM, Christian Schneider
<chris@...> wrote:
> Hi,
>
> I have also woked with the onException clause recently and it worked for me.
> I used the spring dsl though.
> It surely would help if you can create a small example project that shows
> your problem and post it for example
> to a jira ticket. Once there is some code that can be debugged it is
> ususally quite easy to find a solution.
>

Yeah well said. We cant really help you if you just say - Hey it dont work.
Help is much faster if you provide a detailed error report and have a
sample that we can run that demonstrates the issue.

And there are really a lot of unit tests for error handling so I
wonder it could be a mis configuration or whatever on your side.

> Greetings
>
> Christian
>
>
> DRy schrieb:
>>
>> Hi,
>>
>> we use one of the latest 2.1 snapshots (I will have a look at the exact
>> date
>> tomorrow).
>>
>> We use the onException-expressions (from the example below) in a
>> RouteBuilder-class with one defined route. Both onException are placed
>> before the route definition. So far the scope is global.
>>
>>
>> DRy
>>
>>
>> Claus Ibsen-2 wrote:
>>
>>>
>>> What version of Camel are you using?
>>>
>>> And do you use global or route scoped onException ?
>>>
>>> On Thu, Nov 5, 2009 at 3:28 PM, DRy <dirk.rybinski@...> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> if I use two onException expressions in a route definition like this
>>>>
>>>>       onException(UnmarshalException.class)
>>>>           .useOriginalBody()
>>>>           .handled(true)
>>>>               .bean(exceptionLogBean)
>>>>               .process(new Publish2CenterExceptionBean())
>>>>           .end();
>>>>
>>>>       onException(Exception.class)
>>>>           .maximumRedeliveries(-1).redeliveryDelay(1000)
>>>>           .useOriginalBody()
>>>>           .handled(true)
>>>>               .bean(exceptionLogBean)
>>>>           .rollback()
>>>>           .end();
>>>>
>>>> I got two problems:
>>>>
>>>> 1)
>>>> The onEception(Exception.class) part is used all the time! Even if an
>>>> UnmarshalException (direct hit) is thrown. And no matter if I put
>>>> onException(Exception.class)... before
>>>> onException(UnmarshalException.class)... ... ?
>>>>
>>>> 2)
>>>> On the onException(Exception.class) part the bean(exceptionLogBean) is
>>>> never
>>>> called ... ?
>>>>
>>>> What I try to do is, to handle all "known" exception in seperate
>>>> onException(...) parts and install a "last line of defence" with the
>>>> onException(Exception.class).
>>>>
>>>>
>>>> DRy
>>>>
>>
>>
>
>

--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[DRy]

Hi,

I tried to build a small (eclispe) project that shows what happens. To keep this project as small as possible I do not include the used libs to that project but use the lib path from a standard camel "installation" (2.1 Snapshot).  What should I say ... everything works fine in that project ...  ... (-> Murphys Law)

Maybe the strange behavior in my original project has something to do with the used libs ... ? We used to use the libs from the ActiveMQ 5.3 release or 5.4 snapshot and replace all camel-*.jar with that ones from the camel 2.1 snapshot. We also add some needed jars (from camel 2.1 snapshot or other needed projects).  We do this, because we start with activemq and than add some camel functionality.


DRy

[Christian Schneider]

Hi DRy,

it can get quite complicated to handle all those jars by hand. I always
use maven to avoid copying jars around. You should try it if you do not
have another
build system. The camel examples are a good starting point. In any case
it is very important to make sure you don´t mix jars from different
versions.
I always check in my eclipse references that all jars that belong to a
bigger project like camel or spring have the same version number. Even
with maven it can easily happen
that you have for example different version of spring jars if you do not
check your configs.

Greetings

Christian

DRy schrieb:

> Hi,
>
> I tried to build a small (eclispe) project that shows what happens. To keep
> this project as small as possible I do not include the used libs to that
> project but use the lib path from a standard camel "installation" (2.1
> Snapshot).  What should I say ... everything works fine in that project ...
> %-| ... (-> Murphys Law)
>
> Maybe the strange behavior in my original project has something to do with
> the used libs ... ? We used to use the libs from the ActiveMQ 5.3 release or
> 5.4 snapshot and replace all camel-*.jar with that ones from the camel 2.1
> snapshot. We also add some needed jars (from camel 2.1 snapshot or other
> needed projects).  We do this, because we start with activemq and than add
> some camel functionality.
>
>
> DRy
>  

[DRy]

Hi,

I think I've got it ...

On my RouteBuilder-class (see below) I try to catch UnmarshalException in one and all other excpetions in the other onException call.


        onException(UnmarshalException.class)
        .useOriginalBody()
        .handled(true)
            .to("log:onException(UnmarshalException.class)?level=INFO")
        .end();

        onException(Exception.class)
        .useOriginalBody()
        .handled(true)
            .to("log:onException(Exception.class)?level=INFO")
        .end();

        from("activemq:publish?exchangePattern=InOnly&transacted=true")
            .routeId(Publish2CenterRouteBuilder.ROUTE_ID)
            .transacted()
                .process(new Publish2CenterProcessor())
                .multicast()
                    .pipeline()
                        .to("activemq:BonData?exchangePattern=InOnly&transacted=true")
                    .end()
                    .pipeline()
                        .to("activemq:NonBonData?exchangePattern=InOnly&transacted=true")
                    .end()
                 .end()
        .end();


In my processor/bean (Publish2CenterProcessor) if a UnmarshalException is thrown I use the constructor that put in a nested exception (in that case a XMLException from XMLBeans)!!


        throw new UnmarshalException("Could not unmarshal body to XML3!", exception);


As descriped in http://camel.apache.org/exception-clause.html camel will "start from the bottom (nested caused by) and recursive up in the exception hierarchy to find the first matching onException clause". In my case the nested exception (XMLException) will be testet against UnmarshalException (no match) and next against Exception (match). So the intended UnmarshalException will endup in onException(Exception.class).

Why does camel test "from the bottom (nested caused by) and recursive up in the exception hierarchy"  and not vise versa ... ?


... DRy

[Claus Ibsen-2]

On Tue, Nov 10, 2009 at 11:19 AM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
> I think I've got it ...
>
> On my RouteBuilder-class (see below) I try to catch UnmarshalException in
> one and all other excpetions in the other onException call.
>
>
>        onException(UnmarshalException.class)
>        .useOriginalBody()
>        .handled(true)
>            .to("log:onException(UnmarshalException.class)?level=INFO")
>        .end();
>
>        onException(Exception.class)
>        .useOriginalBody()
>        .handled(true)
>            .to("log:onException(Exception.class)?level=INFO")
>        .end();
>
>        from("activemq:publish?exchangePattern=InOnly&transacted=true")
>            .routeId(Publish2CenterRouteBuilder.ROUTE_ID)
>            .transacted()
>                .process(new Publish2CenterProcessor())
>                .multicast()
>                    .pipeline()
>
> .to("activemq:BonData?exchangePattern=InOnly&transacted=true")
>                    .end()
>                    .pipeline()
>
> .to("activemq:NonBonData?exchangePattern=InOnly&transacted=true")
>                    .end()
>                 .end()
>        .end();
>
>
> In my processor/bean (Publish2CenterProcessor) if a UnmarshalException is
> thrown I use the constructor that put in a nested exception (in that case a
> XMLException from XMLBeans)!!
>

Can you show the entire hierarchy of this exception? I guess it could
contain also a caused exception which may be of type Exception or the
likes.

>
>        throw new UnmarshalException("Could not unmarshal body to XML3!",
> exception);
>
>
> As descriped in http://camel.apache.org/exception-clause.html camel will
> "start from the bottom (nested caused by) and recursive up in the exception
> hierarchy to find the first matching onException clause". In my case the
> nested exception (XMLException) will be testet against UnmarshalException
> (no match) and next against Exception (match). So the intended
> UnmarshalException will endup in onException(Exception.class).
>

I guess Exception is too generic and we should take special care for
this one and always wind up the entire hierarchy
to see if there is an 100% match such as the UnmarshalException in your case.


> Why does camel test "from the bottom (nested caused by) and recursive up in
> the exception hierarchy"  and not vise versa ... ?
>

Because the real exception is in the bottom. The middle exceptions is
most often just wrapper exceptions of some sort.


You can write you custom exception policy using ExceptionPolicyStrategy.


>
> ... DRy
>
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26281107.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[Claus Ibsen-2]

Hi

I had a look and created a ticket to improve/fix this issue
https://issues.apache.org/activemq/browse/CAMEL-2158

The current code did stop to eagerly instead of finding better
candidates longer up the exception hierarchy.


On Tue, Nov 10, 2009 at 11:19 AM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
> I think I've got it ...
>
> On my RouteBuilder-class (see below) I try to catch UnmarshalException in
> one and all other excpetions in the other onException call.
>
>
>        onException(UnmarshalException.class)
>        .useOriginalBody()
>        .handled(true)
>            .to("log:onException(UnmarshalException.class)?level=INFO")
>        .end();
>
>        onException(Exception.class)
>        .useOriginalBody()
>        .handled(true)
>            .to("log:onException(Exception.class)?level=INFO")
>        .end();
>
>        from("activemq:publish?exchangePattern=InOnly&transacted=true")
>            .routeId(Publish2CenterRouteBuilder.ROUTE_ID)
>            .transacted()
>                .process(new Publish2CenterProcessor())
>                .multicast()
>                    .pipeline()
>
> .to("activemq:BonData?exchangePattern=InOnly&transacted=true")
>                    .end()
>                    .pipeline()
>
> .to("activemq:NonBonData?exchangePattern=InOnly&transacted=true")
>                    .end()
>                 .end()
>        .end();
>
>
> In my processor/bean (Publish2CenterProcessor) if a UnmarshalException is
> thrown I use the constructor that put in a nested exception (in that case a
> XMLException from XMLBeans)!!
>
>
>        throw new UnmarshalException("Could not unmarshal body to XML3!",
> exception);
>
>
> As descriped in http://camel.apache.org/exception-clause.html camel will
> "start from the bottom (nested caused by) and recursive up in the exception
> hierarchy to find the first matching onException clause". In my case the
> nested exception (XMLException) will be testet against UnmarshalException
> (no match) and next against Exception (match). So the intended
> UnmarshalException will endup in onException(Exception.class).
>
> Why does camel test "from the bottom (nested caused by) and recursive up in
> the exception hierarchy"  and not vise versa ... ?
>
>
> ... DRy
>
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26281107.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[DRy]

Hi,

Claus Ibsen-2 wrote:

I had a look and created a ticket to improve/fix this issue
https://issues.apache.org/activemq/browse/CAMEL-2158

The current code did stop to eagerly instead of finding better
candidates longer up the exception hierarchy.

Nice! Thx!


... DRy

[DRy]

Hi,

Claus Ibsen-2 wrote:

Can you show the entire hierarchy of this exception? I guess it could
contain also a caused exception which may be of type Exception or the
likes.

The UnmarshalException is declared like this

public class UnmarshalException extends Exception {
    ...
}

so the hierachy is

UnmarshalException
    Exception
        Throwable
            Serializable


... DRy

[Claus Ibsen-2]

On Wed, Nov 11, 2009 at 8:15 AM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
>
> Claus Ibsen-2 wrote:
>>
>> I had a look and created a ticket to improve/fix this issue
>> https://issues.apache.org/activemq/browse/CAMEL-2158
>>
>> The current code did stop to eagerly instead of finding better
>> candidates longer up the exception hierarchy.
>>
>
> Nice! Thx!
>

I have committed a fix now. Can you test it on your end?
svn rev: 834801.

>
> ... DRy
>
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26297048.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[DRy]

Hi,

Claus Ibsen-2 wrote:

I have committed a fix now. Can you test it on your end?
svn rev: 834801.

I will test this as soon as possible ...

We do not use the maven repo. How can I find out if this svn rev is in the daily snapshot build ... ?

Your message is dated "Nov 11, 2009; 09:33am" ... this snapshot zip is dated "Wed Nov 11 10:28:51 GMT+00:00 2009" ... so I thing it's included - but I'm not sure.

I tested it with that build ("Wed Nov 11 10:28:51 GMT+00:00 2009") and it didn't work! I throw a UnmarshalException with a nested XMLException (from XMLBeans). The onException(Throwable.class) handled the exception.


... DRy

[Claus Ibsen-2]

On Wed, Nov 11, 2009 at 4:59 PM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
>
> Claus Ibsen-2 wrote:
>>
>> I have committed a fix now. Can you test it on your end?
>> svn rev: 834801.
>>
>
> I will test this as soon as possible ...
>
> We do not use the maven repo. How can I see if this svn rev is in the daily
> snapshot build ... ?
>
> Your message is dated "Nov 11, 2009; 09:33am" ... this snapshot zip is dated
> "Wed Nov 11 10:28:51 GMT+00:00 2009" ... so I thing it's included - but I'm
> not sure.
>

Its Hudson who build and deploy to the Apache snapshot repo
http://hudson.zones.apache.org/hudson/job/Camel/

So I guess build 481 contained the fix which should be at this time
the last deployed.

But try it out and see how goes :)
Otherwise check back tomorrow and see if the jar/zip is newer.


>
> ... DRy
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26303211.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

[DRy]

Hi,

Claus Ibsen-2 wrote:

But try it out and see how goes :)
Otherwise check back tomorrow and see if the jar/zip is newer.

Checked! Works fine!

I tested it with that build from 11. Nov 17:xx:xx! If I throw a UnmarshalException with a nested XMLException (from XMLBeans). The onException(UnmarshalException.class) handled the exception - even if there is a onException(Throwable.class).


... DRy

[Claus Ibsen-2]

On Thu, Nov 12, 2009 at 5:45 PM, DRy <dirk.rybinski@...> wrote:

>
> Hi,
>
>
> Claus Ibsen-2 wrote:
>>
>> But try it out and see how goes :)
>> Otherwise check back tomorrow and see if the jar/zip is newer.
>>
>
> Checked! Works fine!
>
> I tested it with that build from 11. Nov 17:xx:xx! If I throw a
> UnmarshalException with a nested XMLException (from XMLBeans). The
> onException(UnmarshalException.class) handled the exception - even if there
> is a onException(Throwable.class).
>
>

Great glad it works now. Seems also as the most expected what to
happen. So glad we got that fixed in Camel.

> ... DRy
>
> --
> View this message in context: http://old.nabble.com/Exception-handling-...-onException-tp26215607p26322069.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus