camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: Idea - Chained Type Converters (using somekind of smart engine)
Date Tue, 14 Oct 2008 12:24:07 GMT

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
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576

-----Original Message-----
From: James Strachan [] 
Sent: 13. oktober 2008 18:09
Subject: Re: Idea - Chained Type Converters (using somekind of smart engine)

2008/10/12 Claus Ibsen <>:
> 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.
> 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.


Open Source Integration

View raw message