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 Stephan -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Sonntag, 10. April 2016 15:45 To: dev <dev@camel.apache.org> Subject: Re: Concerning Attachments and Attachment Headers in Camel On Thu, Apr 7, 2016 at 2:42 PM, Siano, Stephan <stephan.si...@sap.com> 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 ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
