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
