I converted manually using JAXB directly, like this:

*    final JAXBContext context = JAXBContext.newInstance(LafaList.class);*
*    final Unmarshaller unMarshaller = context.createUnmarshaller();*
*    LafaList lafaList = (LafaList) unMarshaller.unmarshal(new
StreamSource(new StringReader(theExchange.getIn().getBody(String.class))));*

This works while waiting for the next Camel release,

/Bengt

2012/4/18 Bengt Rodehav <be...@rodehav.com>

> Thanks for your suggestion Clause but the lookup in the type converter
> registry failed to find a type converter. Must be a fallback converter
> then. The LafaList class is a JAXB generated class which I assume would
> need the fallback converter.
>
> The only other workaround I can think of is to do the type conversion on
> my own. Do you have any other suggestions Clause?
>
> /Benk
>
>
> 2012/4/18 Claus Ibsen <claus.ib...@gmail.com>
>
>> On Wed, Apr 18, 2012 at 10:10 AM, Bengt Rodehav <be...@rodehav.com>
>> wrote:
>> > 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);
>> >
>>
>> It depends whether the conversion is using a regular type converter or
>> a fallback.
>>
>> If its a regular then you can look it up from the registry, and invoke
>> it manually.
>> Then the exception will be propagated to you.
>>
>> TypeConverter tc =
>> theExchange.getContext().getTypeConverterRegistry().lookup(LafaList.class,
>> theExchange.getIn().getBody.getClass());
>> if (tc != null) {
>>   .. invoke me manually
>>
>>
>> However for a fallback TC its trickier. And hence why the JAXB
>> bug/issue was harder to track down.
>>
>>
>> > 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/
>> >>> >
>> >>>
>> >>
>> >>
>>
>>
>>
>> --
>> 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