camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [HEADS UP] - TypeConverter improved in Camel 2.10
Date Tue, 17 Apr 2012 15:18:51 GMT
+1
Hadrian

On 04/17/2012 05:38 AM, Claus Ibsen 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 converter,
>> 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 allows
>> Camel to detect the (a) failure faster
>> from a fallback type converter (regular non fallback would fail fast already)
>>
>> This means the API is also consistent from caller point of view. You
>> 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 to
>> numeric values.
>>
>> Likewise there is a few other spots where we do this, such as the XSLT
>> component, where we try to use StAX, SAX, before DOM etc.
>> So we have introduced a tryConvertTo API, which would not fail during
>> 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, where
>> 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 simpler
>> basic conversions: String<->  Numeric. And so forth. But over the time
>> we have added those as type converter directly in Camel, as they are
>> 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/
>
>
>

-- 
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Mime
View raw message