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 <[EMAIL PROTECTED]> wrote:
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> 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/

Reply via email to