On Thu, Apr 14, 2016 at 2:51 PM, Siano, Stephan <stephan.si...@sap.com> wrote: > 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? >
I suggest a header that starts with Camel as key, as they are generally informative/meta-data or control headers etc. Exchange properties are not part of the message, and are generally used for other things such as storing EIP details, user data to keep, some other state, message history and whatnot. The message header filter will filter out headers that start with Camel. > 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 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
