Hi Yeah I think this could lead to unforeseen magic happening as well. #1 I hate is when developers loose control.
So -1 as well. We can quickly whirl up the needed converters. Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: 13. oktober 2008 18:09 To: [email protected] Subject: Re: Idea - Chained Type Converters (using somekind of smart engine) 2008/10/12 Claus Ibsen <[EMAIL PROTECTED]>: > Hi > > I have been wondering if it somehow would be possible to let Camel be very > smart when it comes to type converters. We have endpoints, components, etc. > that expect and can only handle certain types. So end-users get sometimes a > issue that their payload type is not compatible. > https://issues.apache.org/activemq/browse/CAMEL-978 > > I was wondering if we could provide some kind of converter logic engine that > could do chained type converters (supporting only standard JDK types, so it's > safe to convert a -> b -> c, and not "loose" information) > > So for instance if you need a InputStream and there is already a type > converter to String, then the engine could do the last step > > Type converter already in the component: > SomeType -> String > > But we need an InputStream type. Then the engine could do the last converter > ions as it's a (String -> InputStream and both types are standard JDK types) > > So the convertions would be: > > SomeType -A-> String -B-> InputStream > > Whereas A: is an existing type converter in the camel component (@Converter) > And B: is the new type converter engine. I did ponder about adding support for this when I originally hacked up the type converter stuff; that if you wanted to go from A -> B but there was no defined mapping, but there was one of A -> C and C-> B then it could use that. My worry was it could lead to some pretty inefficient type conversions - plus the problem of having many possible solutions to pick from. e.g. imagine Cheese -> Document Most things can be turned into a String; and a String can be turned into a Document; but Cheese.toString() might not be XML :) I kinda thought that its maybe a tad too much magic, and we'd be better off just needing to write the necessary converters. I'd rather there not be a converter available (and folks get a clear message of what is missing and how to add the converter) than wacky things happening under the users feet. Unless we just exclude certain types from the chain? e.g. streams/bytes/strings as interchange formats are often not great. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
