Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
MIME-Version: 1.0
In-Reply-To: <acd00e5cad9a49a6a3651e6451d12560@derote13de02.global.corp.sap>
References: <ee0615017db94fb1b3e1ec9db7f1fca6@derote13de02.global.corp.sap>
 <CAGB5yN=rZTUhrShutbJ2rZHqq0etUcGOwYrMV_cJX_m4bbpeAg@mail.gmail.com>
 <122ed6738d4c442b84a6a883bdd094e6@derote13de02.global.corp.sap>
 <CAGB5yNnLE1jSDhhA1muKBp-Ob3FqYfX03jFswseo6XYxzqru9A@mail.gmail.com>
 <4f62f2f1778a49baba25437e8c624618@derote13de02.global.corp.sap>
 <CAGB5yNkX_cwe4V5t4RJVXkU3C0=26k7xmE4tbG0EaGwDF_s0fQ@mail.gmail.com>
 <acd00e5cad9a49a6a3651e6451d12560@derote13de02.global.corp.sap>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Thu, 14 Apr 2016 13:27:47 +0200
Message-ID: 
 <CAGB5yN=CcEg7J-HUbD1iq8Upam028-pd2nj3cS-ffjEsOS23yw@mail.gmail.com>
Subject: Re: Concerning Attachments and Attachment Headers in Camel
To: dev <dev@camel.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.siano@sap.com> wr=
ote:
> Hi Claus,
>
> OK, I will file a JIRA task for Camel 3.0 to renovate the attachment hand=
ling 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 pr=
operty) e.g. named "CamelAttachmentHeaders" of type Map<String, Map<String,=
 String>> (the first string would be the attachment id and the second one t=
he header name, and the third one the header value). The camel-cxf, camel-m=
ail (and maybe other) components would have to be extended to populate and =
consume these header when attachments are written/read from the camel messa=
ge 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 whic=
h extends (and delegates) DataHandler that has an additional Map containing=
 the headers (with appropriate getters and setters). The components that su=
pport 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 i=
t is available. Components that do not support attachment headers should ke=
ep working as before.
>
> Is there a chance that any of these approaches makes it into the main cod=
eline?
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ibsen@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.siano@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 At=
tachment Capable messages (with either implementation option) actually mean=
s 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 Messag=
e objects that are attachment capable or not depending on whether the compo=
nent supports attachments or not. (File consumers create messages without a=
ttachment support, mail(imap) consumers create MailMessages which do suppor=
t attachments).
>> We can also handle InOnly producer endpoints that do or do not support a=
ttachments. If a producer endpoint gets a message that is not attachment ca=
pable, there are no attachments. (so the mail(SMTP) producer will not creat=
e additional attachments for the outgoing mail if the message is not attach=
ment 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 InOu=
t 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 rec=
eives 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 e=
xpect 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.ibsen@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.siano@sap.com> =
wrote:
>>> Hi Claus,
>>>
>>> I tend to disagree on that. I actually think that having a generic Atta=
chment API in Camel does make sense. Having Attachments only as part of Mai=
lMessage 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 t=
o a SOAP endpoint (using the SOAP with Attachments protocol) even though bo=
th endpoint types support attachments.
>>>
>>> However, you are probably right, that the current solution having the a=
ttachments as part of the Message interface is not the best solution for th=
at. I guess it would have been better to have either a kind of AttachmentMe=
ssage interface (that extends Message) or some kind of AttachmentCapable in=
terface (that complements Message). The components supporting attachments c=
ould 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.ibsen@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.siano@sap.com> =
wrote:
>>>> Hi,
>>>>
>>>> Is there anybody available in this list who knows why the attachment h=
andling in Camel is as it is?
>>>>
>>>> I have had a look into this topic with the Camel-Mail and Camel-CXF co=
mponents and would like to discuss my thoughts about that.
>>>>
>>>> In General the attachment handling is designed to support use cases li=
ke MIME-Multipart messages (e.g. in Mail) or attachment formats as SOAP wit=
h attachments (e.g in CXF). An attachment usually has some kind of identifi=
er, a content type, an attachment body and attachment headers. This is at l=
east the case for the Javamail MIME Part (javax.mail.Part) and the CXF mess=
age Attachment (org.apache.cxf.message.Attachment) object.
>>>>
>>>> However the Camel Message interface has a different notion of attachme=
nts, there is only a Map with an identifier (a key) and a DataHandler (repr=
esenting the message body, the content type and the content disposition). T=
herefore there is no representation of any other attachment header. Was tha=
t left out on purpose?
>>>>
>>>> Does it make sense to extend the Camel Message object (org.apache.came=
l.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


--=20
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2