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
