camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siano, Stephan" <>
Subject RE: Concerning Attachments and Attachment Headers in Camel
Date Mon, 11 Apr 2016 05:45:28 GMT
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?

Best regards

-----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:
View raw message