Yes. That does the trick. Thank you!
But shouldn't camel do that for us? Or at least save successfully
retried exceptions in another property?
Am Fr., 8. Feb. 2019 um 17:38 Uhr schrieb Claus Ibsen-2 [via Camel]
<ml+s465427n5829908...@n5.nabble.com>:
>
> Hi
>
> You can store the custom exception as an exchange property before the
> persist, and then retrieve it afterwards when you do the persist.
>
>
> On Fri, Feb 8, 2019 at 9:59 AM Dennis Holunder <[hidden email]> wrote:
>
> >
> > Hi Claus,
> >
> > I was able to redesign the route, so that works as I want. In that
> > context however there is another issue with retrieving the exception
> > from exchange CamelExceptionCaught property.
> >
> > The route catches CustomException exception and in that case saves the
> > body to database. While saving to database the PersistenceException
> > occurs, but is successfully retried. Then the CamelExceptionCaught
> > property contains PersistenceException instead of CustomException.
> >
> > from("direct:start")
> > .onException(CustomException.class)
> > .handled(true)
> > .to(persist) // persist body (will fail, but successfully retry)
> > .to(report) // report custom exception
> >
> > from(persist)
> > .onException(PersistenceException.class)
> > .retry(10)
> > .log("could not persist body")
> >
> > Is there a way to retrieve the original exception without looking
> > exception.getSuppressed() ? Obviously, the retried exception is not
> > interesting, but the failed one.
> >
> > Thanks!
> > Dan
> >
> > Am Mo., 3. Dez. 2018 um 19:05 Uhr schrieb Claus Ibsen-2 [via Camel]
> > <[hidden email]>:
> > >
> > > Hi
> > >
> > > This is by design, to avoid circular onException to trigger in endless.
> > > So try to design your error handling in a more safe manner
> > > On Tue, Nov 13, 2018 at 10:23 AM Dennis Holunder <[hidden email]> wrote:
> > >
> > > >
> > > > Hello,
> > > >
> > > > I have two onException definitions which catch exceptions and send
> > > > them to direct:logerrors endpoint. The second exception might throw an
> > > > exception which should be caught and handled by the first one. But
> > > > this doesn't work. The FatalFallbackErrorHandler kicks in and as the
> > > > result the exception is not logged by direct:logerrors, as I wish. Any
> > > > ideas how to safely implement this?
> > > >
> > > > from(direct:start)
> > > > .onException(UpdateException.class) //retries and logs the
> > > > error
> > > > .handled(true)
> > > > .maximumRedeliveries(5)
> > > > .redeliveryDelay(1_000L)
> > > > .to(direct:logerrors)
> > > > .end()
> > > > .onException(IgnoredException.class) //saves the POJO and
> > > > logs the error
> > > > .handled(true)
> > > > .process().body(Pojo.class, processor::update) //
> > > > throws UpdateException
> > > > .to(direct:logerrors)
> > > > .end()
> > > >
> > > > Regards,
> > > > Dan
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> > >
> > > ________________________________
> > > If you reply to this email, your message will be added to the discussion
> > > below:
> > > http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5826402.html
> > > To unsubscribe from Camel, click here.
> > > NAML
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5829908.html
> To unsubscribe from Camel, click here.
> NAML
