camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Concerning Attachments and Attachment Headers in Camel
Date Thu, 14 Apr 2016 11:27:47 GMT
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> 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.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 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.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 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.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 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

Mime
View raw message