Can you explain the difference scope of:
*errorHandler(deadLetterChannel().exceptionPolicyStrategy(new
ChangeRequestExceptionPolicy()));
onException(ChangeRequestExceptionPolicy.class)
.maximumRedeliveries(1)
.setHeader("ERROR_INFO", constant("Damm my policy
exception"))
.to(Constants.CHANNEL_GG_CS_CR_DEFAULT_ERROR);
*
*verse using:*
*from(Constants.CHANNEL_GG_CS_CR_ADD)
.errorHandler(
deadLetterChannel(Constants.
CHANNEL_GG_CS_CR_ADD_ERROR)
.loggingLevel(LoggingLevel.INFO)
)
.processRef("changeRequestProcessor**")
.recipientList(header(Constants.REQUEST_DESTINATION));*
I am finding that the second example I gave is not working.
When there is an error in my *changeRequestProcessor*, the error gets routed
to *CHANNEL_GG_CS_CR_DEFAULT_ERROR instead of
**CHANNEL_GG_CS_CR_ADD_ERRORas I would expect.
*
On Thu, Oct 2, 2008 at 9:51 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote:
> Hi
>
> If you are using the DeadLetterChannel in Camel it does in fact
> - remove the exception: exchange.setException(null)
> - but its stored elsewhere: exchange.setProperty(FAILURE_HANDLED_PROPERTY,
> exchange.getException()); See the source code for DLC.
>
> So you should be able to get the original caused exception even while
> handling the failure in your own processor code.
>
> We should probably support an easier way to get this information. Somekind
> of method on the exchange.
>
> Please feel free to create a ticket for this. Somekind of public API method
> on Exchange to get this information:
> - is this exchange currently being failure handled
> - what was the original cause of this failure
>
>
>
> You can also do the per exception route:
>
> // regular deadletterchannel here
>
>
> exception(MySuperDuperException.class).to("bean:handleMySuperDuperException);
> exception(MyCoolException.class).to("bean:handleMyCoolException);
>
> // and then the regular routing stuff here
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Mick Knutson [mailto:[EMAIL PROTECTED]
> Sent: 2. oktober 2008 18:37
> To: Camel
> Subject: deadletter verse recipientList design issue
>
> I have not gotten any solutions to my design issue, so I am stepping back
> to
> see if there is another way to accomplish what I am trying to do.
>
> I want to check for message exceptions such as transformation or database
> errors processing incoming messages. My initial thought was to process them
> as deadletters and that works but I have no way of knowing what error
> message that actually occurred and no way to take that error message and
> add
> it to the header so the original message is not modified.
>
> So what else can I do here?
>
> I could just wrap every block in a try/catch, then if I catch and error,
> and
> the error to the header, change the destination, and rout to the dynamic
> recipientList right?
>
>
>
> --
> ---
> Thank You...
>
> Mick Knutson
> BASE Logic, inc.
> (415) 354-4215
>
> Website: http://baselogic.com
> Blog: http://baselogic.com/blog
> BLiNC Magazine: http://blincmagazine.com
> Linked IN: http://linkedin.com/in/mickknutson
> DJ Mick: http://djmick.com
> MySpace: http://myspace.com/mickknutson
> Vacation Rental: http://tahoe.baselogic.com
>
--
---
Thank You…
Mick Knutson
BASE Logic, inc.
(415) 354-4215
Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com
