camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Concerning Attachments and Attachment Headers in Camel
Date Mon, 11 Apr 2016 16:32:11 GMT
On Mon, Apr 11, 2016 at 7:45 AM, Siano, Stephan <> wrote:
> Hi Claus,
> I tend to disagree on that. I actually think that having a generic Attachment API in
Camel does make sense. Having Attachments only as part of MailMessage and e.g. a (currently
non-existing) CXFMessage would mean, that it is e.g. impossible to receive an attachment via
mail and then forward it to a SOAP endpoint (using the SOAP with Attachments protocol) even
though both endpoint types support attachments.
> However, you are probably right, that the current solution having the attachments as
part of the Message interface is not the best solution for that. I guess it would have been
better to have either a kind of AttachmentMessage interface (that extends Message) or some
kind of AttachmentCapable interface (that complements Message). The components supporting
attachments could be using this kind of message. However, do you think that this kind of refactoring
makes sense before Camel 3.0? What would be the way to go for Camel 2.18?

Yeah I like the idea of AttachmentMessage or AttachmentCapable. This
also makes those components stand out that support attachments. That
would possible to do for Camel 3.0 where we can do such an API change.
As its only a few components it wont hurt.

So I suggest to log a JIRA for that for Camel 3.0.

> Best regards
> Stephan
> -----Original Message-----
> From: Claus Ibsen []
> Sent: Sonntag, 10. April 2016 15:45
> To: dev <>
> Subject: Re: Concerning Attachments and Attachment Headers in Camel
> On Thu, Apr 7, 2016 at 2:42 PM, Siano, Stephan <> wrote:
>> Hi,
>> Is there anybody available in this list who knows why the attachment handling in
Camel is as it is?
>> I have had a look into this topic with the Camel-Mail and Camel-CXF components and
would like to discuss my thoughts about that.
>> In General the attachment handling is designed to support use cases like MIME-Multipart
messages (e.g. in Mail) or attachment formats as SOAP with attachments (e.g in CXF). An attachment
usually has some kind of identifier, a content type, an attachment body and attachment headers.
This is at least the case for the Javamail MIME Part (javax.mail.Part) and the CXF message
Attachment (org.apache.cxf.message.Attachment) object.
>> However the Camel Message interface has a different notion of attachments, there
is only a Map with an identifier (a key) and a DataHandler (representing the message body,
the content type and the content disposition). Therefore there is no representation of any
other attachment header. Was that left out on purpose?
>> Does it make sense to extend the Camel Message object (org.apache.camel.Message)?
A change here would run rather deep so I would like to discuss this first before I try to
contribute anything in this area.
> The attachments are only used in a few components. It was added when
> Camel was created due the inspiration from JBI / XML world.
> But today we know better and IMHO the attachments should be
> deprecated/removed from the generic api, and only those components
> that want to use it, should have their own. People may mistakenly
> think that file/ftp/ and other components uses the attachments, but
> they do not.
> Then MailMessage and CxfMessage etc can have their attachments api.
>> Best regards
>> Stephan
> --
> Claus Ibsen
> -----------------
> @davsclaus
> Camel in Action 2:

Claus Ibsen
----------------- @davsclaus
Camel in Action 2:

View raw message