+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.ib...@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: cib...@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/
