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