Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ0TPGJWJFTpX3UQCgY8fiHfqR1=QXxjQ7eAa2y4Hya2wX4Xhw@mail.gmail.com>
References: 
 <CAGB5yN=Zii-hjt5Vtdr1WNYHfpNXNwHuRHDWXBgonYOH8E=N_g@mail.gmail.com>
 <CAGB5yN=Lp+s67eat5_QjN=n9miTS2S9-VJGL7eYvT-k+wmupFw@mail.gmail.com>
 <CALvzYd8DFMYDhVKizPfysHT0hGPyZNLj8cG7gSZbugkhLNfFqg@mail.gmail.com>
 <CAJ0TPG+F5eBcwHqHQ7s8y+u3Bxu_EsSisOWBKDeZ=_c5h77APg@mail.gmail.com>
 <CAJ0TPGJWJFTpX3UQCgY8fiHfqR1=QXxjQ7eAa2y4Hya2wX4Xhw@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Wed, 18 Apr 2012 10:25:15 +0200
Message-ID: 
 <CAGB5yNnSJVQQ7-Tr6h6YsiORwx8BDDoJz=uV5b5i64XQVQisMA@mail.gmail.com>
Subject: Re: [HEADS UP] - TypeConverter improved in Camel 2.10
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 10:10 AM, Bengt Rodehav <bengt@rodehav.com> wrote:
> BTW, is there a workaround that can be used in Camel 5.9.1?
>
> I have this today:
>
> =A0 =A0LafaList lafaList =3D theExchange.getIn().getBody(LafaList.class);
>
> I've tried with this:
>
> =A0 =A0LafaList lafaList =3D
> theExchange.getIn().getMandatoryBody(LafaList.class);
>

It depends whether the conversion is using a regular type converter or
a fallback.

If its a regular then you can look it up from the registry, and invoke
it manually.
Then the exception will be propagated to you.

TypeConverter tc =3D
theExchange.getContext().getTypeConverterRegistry().lookup(LafaList.class,
theExchange.getIn().getBody.getClass());
if (tc !=3D null) {
   .. invoke me manually


However for a fallback TC its trickier. And hence why the JAXB
bug/issue was harder to track down.


> In the first case I get null if the type conversion fails (due to an
> invalid XML message). In the second case I get an exception. Unfortunatel=
y
> both cases cause all subesequent conversions to fail even if the XML
> message is valid.
>
> Is there any way I can get this to work without having to wait for a new
> Camel version?
>
> /Bengt
>
> 2012/4/18 Bengt Rodehav <bengt@rodehav.com>
>
>> +1
>>
>> I've just spent two days trying to figure out what I did wrong. I =A0had=
 a
>> case where all subsequent xml conversions would fail after I tried to
>> process one xml message in invalid format. Then I found your post. Good =
job
>> fixing it.
>>
>> /Bengt
>>
>>
>> 2012/4/17 Christian M=FCller <christian.mueller@gmail.com>
>>
>>> +1,
>>>
>>> and thanks for your hard work...
>>>
>>> Best,
>>> Christian
>>>
>>> On Tue, Apr 17, 2012 at 11:38 AM, Claus Ibsen <claus.ibsen@gmail.com>
>>> wrote:
>>>
>>> > Hi
>>> >
>>> > I am inclined to backport these changes to the 2.9 branch as I think
>>> > the bug from CAMEL-5164 would bite other people as well.
>>> > I have a workaround patch for 2.9 branch as work in progress. But I
>>> > dont feel its an optimal solution, as would the backport of the
>>> > changes from 2.10.
>>> >
>>> > There is only a slight API change in TypeConverter. Most people would
>>> > use the @Converter for their custom converters, and if so, then they
>>> > are okay (no problem there). Only for people who implement the
>>> > TypeConverter directly, and then add that directly to the
>>> > TypeConverterRegistry API. Frankly I dont see this used at all by end
>>> > users (The @Converter is mich simpler).
>>> >
>>> > However there is a slight change in the API from Message.getBody(type=
)
>>> > and Message.getHeader(name, Type), as they would now throw a
>>> > TypeConversionException if failing. Where as beforehand a WARN would
>>> > be logged and null returned.
>>> >
>>> > IMHO the changes from 2.10 is better and also allows end users to be
>>> > in control of the failure first-hand. And frankly also what I would
>>> > expect from the call.
>>> >
>>> > If nobody scream, then we should get this backported for the next 2.9=
.3
>>> > release.
>>> >
>>> > Any thoughts?
>>> >
>>> >
>>> > PS: I have attached my ugly workaround patch. We can use that as a
>>> > backup if someone scream really loud.
>>> >
>>> >
>>> >
>>> > On Tue, Apr 17, 2012 at 7:46 AM, Claus Ibsen <claus.ibsen@gmail.com>
>>> > wrote:
>>> > > Hi
>>> > >
>>> > > Recently I have spent some time to improve the type converters in
>>> Camel
>>> > 2.10.
>>> > >
>>> > > Most significant is the following changes
>>> > > a) fix important bug
>>> > > b) Fail fast
>>> > > c) tryConvertTo
>>> > > d) Expose utilization statistics
>>> > >
>>> > >
>>> > > Ad a)
>>> > > A bug was reported in
>>> https://issues.apache.org/jira/browse/CAMEL-5164
>>> > >
>>> > > In summary if using camel-jaxb that offers a fallback type converte=
r,
>>> > > and a failure occurs during XML marshalling,
>>> > > then subsequent new XML messages may fail, despite they were okay.
>>> > >
>>> > > Ad b)
>>> > > Due to a we need to detect this faster and better. So now the type
>>> > > converter system in Camel will fail fast
>>> > > by throwing a new TypeConversionException (its runtime). That allow=
s
>>> > > Camel to detect the (a) failure faster
>>> > > from a fallback type converter (regular non fallback would fail fas=
t
>>> > already)
>>> > >
>>> > > This means the API is also consistent from caller point of view. Yo=
u
>>> > > get a TypeConversionException if there
>>> > > was a failure during a type conversion attempt.
>>> > >
>>> > > Ad c)
>>> > > There is some places in camel-core where we want to only try to
>>> > > convert. For example with the binary predicates
>>> > > where you want to compare if X > Y. Then we try to coerce X and Y t=
o
>>> > > numeric values.
>>> > >
>>> > > Likewise there is a few other spots where we do this, such as the X=
SLT
>>> > > component, where we try to use StAX, SAX, before DOM etc.
>>> > > So we have introduced a tryConvertTo API, which would not fail duri=
ng
>>> > > type conversion.
>>> > >
>>> > > Ad d)
>>> > > The type converter system is used a lot in Camel during routing
>>> > > messages. Now we expose utilization statistics,
>>> > > which allow end users to spot if there is too many missing type
>>> > > conversion attempts. For example a route may attempt to convert, wh=
ere
>>> > > there is no suitable type converter. This can now more easily be
>>> > > spotted, allowing the end user to either. Implement such a missing
>>> > > type converter, or
>>> > > correct a mistake in his application or the likes.
>>> > >
>>> > > The statistics is exposed in JMX and as well when Camel shutdown as=
 a
>>> > log line.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On another note I am also hunting down to avoid using the
>>> > > PropertiesEditorTypeConverter, as it has many flaws
>>> > > - its not thread safe
>>> > > - its slow
>>> > > - and 3rd party projects can add property editors that influence
>>> > > Camel's type converts (eg ActiveMQ has a String -> List) properties
>>> > > editor that turns a String into a List of ActiveMQDestination
>>> > > instances.
>>> > > - it does not understand generics in List/Collection type, eg the
>>> > > ActiveMQ example above
>>> > >
>>> > > And basically we uses it only in Camel for doing some of the simple=
r
>>> > > basic conversions: String <-> Numeric. And so forth. But over the t=
ime
>>> > > we have added those as type converter directly in Camel, as they ar=
e
>>> > > faster as well.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Claus Ibsen
>>> > > -----------------
>>> > > CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
>>> > > FuseSource
>>> > > Email: cibsen@fusesource.com
>>> > > Web: http://fusesource.com
>>> > > Twitter: davsclaus, fusenews
>>> > > Blog: http://davsclaus.blogspot.com/
>>> > > Author of Camel in Action: http://www.manning.com/ibsen/
>>> >
>>> >
>>> >
>>> > --
>>> > Claus Ibsen
>>> > -----------------
>>> > CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
>>> > FuseSource
>>> > Email: cibsen@fusesource.com
>>> > Web: http://fusesource.com
>>> > Twitter: davsclaus, fusenews
>>> > Blog: http://davsclaus.blogspot.com/
>>> > Author of Camel in Action: http://www.manning.com/ibsen/
>>> >
>>>
>>
>>


--=20
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/