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?
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?).
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?
-----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
