+1 I've just spent two days trying to figure out what I did wrong. I had 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üller <christian.muel...@gmail.com> > +1, > > and thanks for your hard work... > > Best, > Christian > > On Tue, Apr 17, 2012 at 11:38 AM, Claus Ibsen <claus.ib...@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.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/ > > >
