Hi Claus, I have filed CAMEL-9868 for the Camel 3.0 changes.
I will try out both options for Camel 2.x at least on a POC level and come back with the results. For comparing the results is it better to create a JIRA item for that or should I better post it at this list? One question concerning Option 1: is it better to have a Camel header or an exchange property for this? Best regards Stephan -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Donnerstag, 14. April 2016 13:28 To: dev <dev@camel.apache.org> Subject: Re: Concerning Attachments and Attachment Headers in Camel Hi Yeah both approaches are doable. But I think the first one is the least invasive and fits 2.x the best. On Thu, Apr 14, 2016 at 11:19 AM, Siano, Stephan <stephan.si...@sap.com> wrote: > Hi Claus, > > OK, I will file a JIRA task for Camel 3.0 to renovate the attachment handling > in the message interface as we discussed below. > > As for the 2.18 extensions: > > What exactly do you mean with "you can try using headers"? > > One option would be to introduce a header (or maybe better an exchange > property) e.g. named "CamelAttachmentHeaders" of type Map<String, Map<String, > String>> (the first string would be the attachment id and the second one the > header name, and the third one the header value). The camel-cxf, camel-mail > (and maybe other) components would have to be extended to populate and > consume these header when attachments are written/read from the camel message > objects. I guess this is possible, but it's quite ugly (and I am unsure how > to keep this consistent). > > A second compatible option would be to create a new Attachment class which > extends (and delegates) DataHandler that has an additional Map containing the > headers (with appropriate getters and setters). The components that support > this are extended in a way that if they write Attachment objects into the > attachment map of the message and use the headers stored in there if it is > available. Components that do not support attachment headers should keep > working as before. > > Is there a chance that any of these approaches makes it into the main > codeline? > > Best regards > Stephan > > -----Original Message----- > From: Claus Ibsen [mailto:claus.ib...@gmail.com] > Sent: Donnerstag, 14. April 2016 09:49 > To: dev <dev@camel.apache.org> > Subject: Re: Concerning Attachments and Attachment Headers in Camel > > On Wed, Apr 13, 2016 at 11:51 AM, Siano, Stephan <stephan.si...@sap.com> > wrote: >> Hi Claus, >> >> Sorry for the late reply, but I had to do some thinking about this issue >> (and was busy with other things yesterday). >> >> Having the different interfaces for Messages (without attachment) and >> Attachment Capable messages (with either implementation option) actually >> means that we will have message implementations that do support attachments >> and other implementations that do not. >> >> With this model we can handle all consumer endpoints. They create Message >> objects that are attachment capable or not depending on whether the >> component supports attachments or not. (File consumers create messages >> without attachment support, mail(imap) consumers create MailMessages which >> do support attachments). >> We can also handle InOnly producer endpoints that do or do not support >> attachments. If a producer endpoint gets a message that is not attachment >> capable, there are no attachments. (so the mail(SMTP) producer will not >> create additional attachments for the outgoing mail if the message is not >> attachment capable and the file producer will just ignore that stuff >> altogether). >> >> However I see an issue if we have a producer endpoint that is doing InOut >> communication and supports attachments. Examle: we have a route like >> from("file:..").to("cxf:bean:replies_with_an_attachment").to("smtp:mailrelay") >> What is this endpoint type (CXF in the example) supposed to do if it >> receives a message without attachment supports, sends it out as a request >> and then gets a reply containing attachments? Create a new message? As I see >> it current message implementations usually do not create new message objects >> but only set the headers and bodies on existing ones. Is this a good idea? >> What do you think? >> > > Yeah sure there is components that has their own message > implementation such as MailMessage, JmsMessage, etc. The CXF would > then set the OUT as a new CxfMessage where it sets the headers / body > / attachments as it needs. > > > >> Furthermore filing a JIRA task for Camel 3.0 won't help anytime soon. Do you >> have any idea about the timeframe of a Camel 3.0 release? I wouldn't expect >> that anytime soon, but do you think it is realistic to see a Camel 3.0 >> release e.g. next year (or in 2018 or so?). >> > > API changes in Exchange / Message / Processor or whatnot that are > central cannot easily be done on 2.x, and should defer to 3.x. > >> Maybe we can find a way to get attachment headers into the Camel message in >> a more compatible way that could be included in Camel 2.18 or so. What do >> you think about that? >> > > Yeah you can try using headers > > >> -----Original Message----- >> From: Claus Ibsen [mailto:claus.ib...@gmail.com] >> Sent: Montag, 11. April 2016 18:32 >> To: dev <dev@camel.apache.org> >> Subject: Re: Concerning Attachments and Attachment Headers in Camel >> >> 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 > > > > -- > 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
