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? -- James ------- http://macstrac.blogspot.com/
