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/ -- 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/
