Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.218.211 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=c8S+HpS9HMcTiWeCyLzpIihqakT606Mcw5Lyt85M7VgQqSiJ3dWDqxV8mHpwm38RYg
         sB3es2k9sbMXGTQpXbqfzSeIgRGyHaUMpzvO6KQsFu9m7fuM2Vq5aRXSxNXWeEeOIroc
         /3osRYELxusnx3Oo94Y97Size45KA/h91OJaY=
MIME-Version: 1.0
In-Reply-To: <5380c69c0911250744x3cb3629fo6bf33f92e2de6159@mail.gmail.com>
References: <26514451.post@talk.nabble.com>
 <5380c69c0911250744x3cb3629fo6bf33f92e2de6159@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Wed, 25 Nov 2009 16:47:14 +0100
Message-ID: <5380c69c0911250747r701db7e6oedc2851cc3db0d3d@mail.gmail.com>
Subject: Re: Camel 1.6.1 - Capturing parsing errors from Validation Component
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

And if you wrote a little unit test you could just add a processor and
use a debugger to check what the Exchange contains of data and find
what you are looking for.

Also you can use the Tracer which also exists for 1.x. it can output
what the Exchange contains at runtime to a log. Then you will find
that caught exception somewhere
http://camel.apache.org/tracer


On Wed, Nov 25, 2009 at 4:44 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> Hi
>
> Yeah unfortunately the wiki documentation is not divided between 1.6 and =
2.x.
> Confluence kinda sucks for that.
>
> Anyway the the validator wiki page has an example
> http://camel.apache.org/validation.html
>
> However the catch in Camel 1.x does not carry that caught exception.
> That one is avail in 2.0.
> So you cannot use that.
>
> However the onException has it so you just need to look the right place.
>
> Its stored in a header with the key
> Exception cause =3D
> exchange.getIn().getHeader(DeadLetterChannel.CAUGHT_EXCEPTION_HEADER,
> Exception.class);
>
> And you gotta use handled(true) in this case if you want to handle
> this failure yourself and write a new message to that file:error
>
>
>
>
> On Wed, Nov 25, 2009 at 4:14 PM, jweathers777 <johnweathers@gmail.com> wr=
ote:
>>
>> I have a simple pair of routes that look like this:
>>
>> from("file:///input?delete=3Dtrue").convertBodyTo(String.class).to("dire=
ct:validation");
>>
>> from("direct:validation").to("validator:test.xsd").to("file:///output");
>>
>> I've been trying all sorts of ways to trap the SchemaValidationException=
 so
>> that I can extract the parsing errors in an invalid XML file and combine
>> them with the original message into a wrapper message to be routed to
>> another endpoint "file:///error".
>>
>> Among the many ways that I have tried is this one:
>> onException(SchemaValidationException.class).handled(false)
>> =A0 .process(new ErrorBundler()).to("file:///error");
>>
>> Then, in my Processor, I try construct my wrapper message from the passe=
d in
>> exchange, but no matter what I do, the Exception is null and so I cannot
>> access the parse errors.
>>
>> I've tried exchange.getException(), exchange.getFault(), and
>> exchange.getProperty(Exchange.EXCEPTION_HANDLED_PROPERTY, Throwable).
>>
>> All of them have NULL.
>>
>> One very ugly way that I managed to obtain the desired effect was to rep=
lace
>> my validation route with this:
>> from("direct:validation").to("validator:test.xsd").process(new
>> HackProcessor());
>>
>> My processor's body uses a Java try catch block to wrap a block of code
>> where I use exchange.getContext().createProducerTemplate() to manually s=
end
>> an exchange to the validator endpoint and then send the successful resul=
t to
>> my output file endpoint. In the case where the exception is thrown, I
>> construct my wrapper message and can successfully examine the Exception
>> message and data in order to send my wrapper message on to my error
>> endpoint.
>>
>> While the above "works", it feels like a hack and I suspect that I must =
be
>> missing something with the normal Camel onException mechanism.
>>
>> --
>> View this message in context: http://old.nabble.com/Camel-1.6.1---Captur=
ing-parsing-errors-from-Validation-Component-tp26514451p26514451.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
>


--=20
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