ServiceMix 4.0 and type converters

[James Strachan <ja...@gmail.com>]

I thought I'd spin up another thread on this...

On 8/23/07, Brian O'Neill <bo...@alumni.brown.edu> wrote:
> On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
> > Exchanges can be created using the Channel#createExchange method.
> > The only change I'd like to
> > integrate in the messaging API is to allow for non xml payloads and
> > maybe untyped attachments.  The body
> > could be converted automatically to a given type if supported (I
> > think Camel does it nicely, so I'm thinking of
> > shamelessly copying the converter layer).  I have added a few helper
> > methods on the exchanges and
> > messages (copy, copyFrom, ensureReReadable, display) to ease message
> > management.
> >
>
> I haven't looked at Camel converters, but would you consider adding a
> contentType and contentEncoding mimicing the headers of HTTP & SIP.
> The endpoint can then use the type and encoding to determine how to
> handle the content.

Incidentally thats come up recently in Camel too; the type converter
stuff is so useful, folks wanna use it for many different things when
the Java class/interface is not enough to specify a conversion. e.g.
convert to Java Object using JAXB2 versus serialization versus SOAP
encoding

I guess this is no longer type conversion, but more content conversion
- so maybe a separate API is required. But certainly folks wanna be
able to do things like

// specify the required Java type and content type
InputStream in = message.getBody(InputStream.class, "application/xml");

But am wondering if for things like content type / content encoding
stuff we need a separate kind of mechanism than the Java type
conversion stuff; or if we could just extend the model to include
content type as well?

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

Re: ServiceMix 4.0 and type converters

[Nodet Guillaume <gn...@gmail.com>]

On Aug 23, 2007, at 1:48 PM, James Strachan wrote:

> I thought I'd spin up another thread on this...
>
> On 8/23/07, Brian O'Neill <bo...@alumni.brown.edu> wrote:
>> On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>> Exchanges can be created using the Channel#createExchange method.
>>> The only change I'd like to
>>> integrate in the messaging API is to allow for non xml payloads and
>>> maybe untyped attachments.  The body
>>> could be converted automatically to a given type if supported (I
>>> think Camel does it nicely, so I'm thinking of
>>> shamelessly copying the converter layer).  I have added a few helper
>>> methods on the exchanges and
>>> messages (copy, copyFrom, ensureReReadable, display) to ease message
>>> management.
>>>
>>
>> I haven't looked at Camel converters, but would you consider adding a
>> contentType and contentEncoding mimicing the headers of HTTP & SIP.
>> The endpoint can then use the type and encoding to determine how to
>> handle the content.
>
> Incidentally thats come up recently in Camel too; the type converter
> stuff is so useful, folks wanna use it for many different things when
> the Java class/interface is not enough to specify a conversion. e.g.
> convert to Java Object using JAXB2 versus serialization versus SOAP
> encoding
>
> I guess this is no longer type conversion, but more content conversion
> - so maybe a separate API is required. But certainly folks wanna be
> able to do things like
>
> // specify the required Java type and content type
> InputStream in = message.getBody(InputStream.class, "application/ 
> xml");
>
> But am wondering if for things like content type / content encoding
> stuff we need a separate kind of mechanism than the Java type
> conversion stuff; or if we could just extend the model to include
> content type as well?

I agree.  The type converter api is not necessarily the best suited  
for our
needs here and may be more suited for converting properties rather
than the body.  There are lots of different things here.  We need to  
be able to send
xml documents, binary streams and POJOs: this would cover most of the  
needs
I guess.  Then, some content type may be able to be converted from  
one format to
another: a jaxb2 pojo may be transformed to xml, a JSON stream may be  
converted
to xml too using http://jettison.codehaus.org/), but I'm not sure how  
far we should go
as there may be lots of different ways to convert data between  
different formats.
Complex transformations may need to be more tightly controlled by  
using an endpoint.

Cheers,
Guillaume Nodet

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

Re: ServiceMix 4.0 and type converters

[Bruce Snyder <br...@gmail.com>]

On 8/23/07, James Strachan <ja...@gmail.com> wrote:

> > I haven't looked at Camel converters, but would you consider adding a
> > contentType and contentEncoding mimicing the headers of HTTP & SIP.
> > The endpoint can then use the type and encoding to determine how to
> > handle the content.
>
> Incidentally thats come up recently in Camel too; the type converter
> stuff is so useful, folks wanna use it for many different things when
> the Java class/interface is not enough to specify a conversion. e.g.
> convert to Java Object using JAXB2 versus serialization versus SOAP
> encoding
>
> I guess this is no longer type conversion, but more content conversion
> - so maybe a separate API is required. But certainly folks wanna be
> able to do things like
>
> // specify the required Java type and content type
> InputStream in = message.getBody(InputStream.class, "application/xml");
>
> But am wondering if for things like content type / content encoding
> stuff we need a separate kind of mechanism than the Java type
> conversion stuff; or if we could just extend the model to include
> content type as well?

I view type conversion (e.g., java.io.File to org.xml.sax.InputSource)
as being very different than content conversion (e.g., EDI to SOAP).
But I do see that sometimes there is some overlap between these two
concepts. Is it a good idea to lump these two together in the same API
when the business purpose is distinctly different?

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/