BTW, is there a workaround that can be used in Camel 5.9.1?

I have this today:

    LafaList lafaList = theExchange.getIn().getBody(LafaList.class);

I've tried with this:

    LafaList lafaList =
theExchange.getIn().getMandatoryBody(LafaList.class);

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. Unfortunately
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 <be...@rodehav.com>

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

Reply via email to