Idea - Chained Type Converters (using somekind of smart engine)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Idea - Chained Type Converters (using somekind of smart engine)

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



Med venlig hilsen

Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

Reply | Threaded
Open this post in threaded view
|

Re: Idea - Chained Type Converters (using somekind of smart engine)

jstrachan
2008/10/12 Claus Ibsen <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

RE: Idea - Chained Type Converters (using somekind of smart engine)

Claus Ibsen
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:[hidden email]]
Sent: 13. oktober 2008 18:09
To: [hidden email]
Subject: Re: Idea - Chained Type Converters (using somekind of smart engine)

2008/10/12 Claus Ibsen <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Idea - Chained Type Converters (using somekind of smart engine)

jstrachan
2008/10/14 Claus Ibsen <[hidden email]>:
> 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.

It would be nice to document the available converters we have so folks
can more easily spot missing converters. Maybe we just need to build
on / document / publicise this?
https://issues.apache.org/activemq/browse/CAMEL-11


--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: Idea - Chained Type Converters (using somekind of smart engine)

Jon Anstey
James Strachan wrote:

> 2008/10/14 Claus Ibsen <[hidden email]>:
>  
>> 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.
>>    
>
> It would be nice to document the available converters we have so folks
> can more easily spot missing converters. Maybe we just need to build
> on / document / publicise this?
> https://issues.apache.org/activemq/browse/CAMEL-11
>
>
>  
Cool. I didn't even know we had this plugin! I think this will do for now:

http://cwiki.apache.org/confluence/display/CAMEL/List+of+Type+Conversions