On Mon, Apr 11, 2016 at 7:45 AM, Siano, Stephan <stephan.si...@sap.com> 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 [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 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
