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: [DISCUSS] Attachment Headers
Date Tue, 19 Jul 2016 11:07:30 GMT
Just edit the release notes at
http://camel.apache.org/camel-2180-release.html

You are welcome to create a new wiki page with more details, such as
the heads up email you wrote, and then link from the release notes to
this wiki page.

On Tue, Jul 19, 2016 at 12:55 PM, Siano, Stephan <stephan.siano@sap.com> wrote:
> Hi Claus,
>
> How do I provide input for the 2.18 release notes?
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Sent: Dienstag, 19. Juli 2016 11:56
> To: dev <dev@camel.apache.org>
> Subject: Re: [DISCUSS] Attachment Headers
>
> Hi
>
> Sounds good.
> Javadoc is good for documenting this kind of APIs.
>
> Some details on the 2.18 release note would be good.
> And good idea with the [HEADS UP].
>
> When we get rid of the wiki documentation and document from the source
> with the ascii doc which we also tie to a new website, then its a good
> place to start overhauling and improving our documentation on the
> online Camel website.
>
>
>
>
>
>
>
> On Mon, Jul 18, 2016 at 2:51 PM, Siano, Stephan <stephan.siano@sap.com> wrote:
>> Hi Claus,
>>
>> Thank you for your feedback. I have polished the code a little in order to be submitted
(added support for multi-value headers in the Attachment interface and default implementation,
added Javadoc, added tests, added support in the camel-jetty9).
>>
>> I am currently in the process of running the tests. What else needs to be done besides
committing the change itself. Update some architecture Wiki (I couldn't find anything about
attachments, though)? The Javadoc should be updated with the commit itself.
>>
>> I guess it might be a good idea to write a heads up mail to this list. Anything else
I have forgotten?
>>
>> Best regards
>> Stephan
>>
>> -----Original Message-----
>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Sent: Freitag, 15. Juli 2016 12:14
>> To: dev <dev@camel.apache.org>
>> Subject: Re: [DISCUSS] Attachment Headers
>>
>> Hi
>>
>> Thanks for bringing this up to attention.
>> I read your proposals and very good with the pros/cons of them.
>>
>> Yeah I also think its better to go with #3 so we get a better solution
>> for this which we carry forward for Camel 3, and have @deprecated the
>> old api on 2.x.
>>
>> +1 for option #3.
>>
>>
>>
>>
>> On Mon, Jul 11, 2016 at 3:31 PM, Siano, Stephan <stephan.siano@sap.com> wrote:
>>> Hi,
>>>
>>> Unfortunately I have received no feedback about this so far.
>>>
>>> If nobody objects I will go on with the implementation for option 3 and check
that into the master branch sometime next week.
>>>
>>> If anybody here has doubts about this please speak up!
>>>
>>> Best regards
>>> Stephan
>>>
>>> -----Original Message-----
>>> From: Franz Paul Forsthofer [mailto:emc2fpf@googlemail.com]
>>> Sent: Donnerstag, 7. Juli 2016 14:40
>>> To: dev@camel.apache.org
>>> Subject: [DISCUSS] Attachment Headers
>>>
>>> Hello,
>>>
>>> In https://issues.apache.org/jira/browse/CAMEL-9880 Stephan proposes an
>>> improvement for the attachment concept in Camel.
>>> He introduces headers for  attachments. Currently an attachment is
>>>  represented in Camel by a DataHandler; in the Camel
>>> Message you have methods like
>>>
>>>
>>>  DataHandler getAttachment(String id);
>>>
>>>  Map<String, DataHandler> getAttachments();
>>>
>>> void addAttachment(String id, DataHandler content);
>>>
>>> void setAttachments(Map<String, DataHandler> attachments);
>>>
>>>
>>> These methods do not cover attachment specific headers; the DataHandler
>>> object contains only the body, the name,
>>> and mime type of the attachment.
>>>
>>>
>>> I see currently three use cases for attachment headers.
>>>
>>> 1.       SOAP messages sent to Camel via CXF can contain attachments with
>>> headers.
>>> Currently these attachment headers get lost when the CXF Message is
>>> transformed to the Camel Message.
>>>
>>>
>>> 2.       Mime Multipart Data Type Formatter
>>> The Mime Multipart Data Type Formatter (
>>> http://camel.apache.org/mime-multipart.htm) converts a Mime Multipart
>>> document
>>> into a Camel message with attachments. The first part of the multipart
>>> document is transformed to the message body, the other
>>> parts are transformed to DataHandler instances. The headers of the parts
>>> currently get lost during this transformation.
>>>
>>> Example of a multipart message from https://tools.ietf.org/html/rfc2387:
>>>
>>>      Content-Type: Multipart/Related; boundary=example-1
>>>              start="<950120.aaCC@XIson.com>";
>>>              type="Application/X-FixedRecord"
>>>              start-info="-o ps"
>>>
>>>      --example-1
>>>      Content-Type: Application/X-FixedRecord
>>>      Content-ID: <950120.aaCC@XIson.com>
>>>
>>>      25
>>>      10
>>>      34
>>>      10
>>>      25
>>>      21
>>>      26
>>>      10
>>>      --example-1
>>>
>>>      Content-Type: Application/octet-stream
>>>      Content-Description: The fixed length records
>>>      Content-Transfer-Encoding: base64
>>>      Content-ID: <950120.aaCB@XIson.com>
>>>
>>>
>>>      T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
>>>      BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
>>>      IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
>>>      BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
>>>      YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
>>>      NrIHF1YWNrCkUgSSBFIEkgTwo=
>>>
>>>      --example-1--
>>>
>>>
>>> The header “Content-Description: The fixed length records” gets lost if the
>>> example Multipart message is transformed to a Camel Message.
>>>
>>>
>>> 3.  An e-Mail can be a Multipart MIME message which contains parts with
>>> headers, example from http://www.oreilly.com/openbook/mh/mulmes.htm:
>>>
>>>
>>> From: Laura Rios <laura@oara.sf.ca.us>
>>> To: steve@ntecom.za
>>> Subject: Sara is two!
>>> Mime-Version: 1.0
>>> Content-Type: multipart/mixed; boundary="Snip snip snip"
>>>
>>> --Snip snip snip
>>> Content-Type: text/enriched; charset="us-ascii"
>>>
>>>
>>> Hi, Steve.  Sara had her second birthday yesterday.  Can you believe it?
>>> She is so <bold>big</bold>!  Now if we can just live through the
>>> "terrible twos" for a year, <italic>sigh</italic>.
>>>
>>> Here are a few words from her.  I've also scanned in a picture of her
>>> party.  Tell your boss thanks for letting us keep in touch by email.
>>>
>>> Laura
>>>
>>> --Snip snip snip
>>> Content-type: audio/basic
>>> Content-transfer-encoding: base64
>>> Content-description: Sara says "I love you, Steve" (awww)
>>>
>>> /Xr++/hoX2lqeXt8d/7z8/D5+PLw7/b+9fD09319/vz5f3j//Pz9fHp7fvrs9Wz/eH59d
>>>    omitted...
>>> /////////////////y8=
>>>
>>> --Snip snip snip
>>>
>>> Content-type: image/gif
>>> Content-transfer-encoding: base64
>>> Content-description: Cutting the cake, sort of
>>>
>>> R0lGODdhQAHIAKMAAAAAAP+2bQAAACQAAAAASEgAAAAkSEgkJG0kJJEkAABIkZFIJCRttrZt
>>>    omitted...
>>> l7Vry4B9aM+yKjifMosAADs=
>>>
>>>
>>> --Snip snip snip--
>>>
>>>
>>>
>>> This example mail message is transformed by the Camel mail component to a
>>> Camel message,
>>> however the attachment headers “Content-description: Sara says "I love you,
>>> Steve" (awww)” and “Content-description: Cutting the cake, sort of” get
>>> lost.
>>>
>>>
>>> These use cases show that attachment headers would bring a valuable
>>> improvement for Camel. Therefore I think the
>>> improvement proposed in https://issues.apache.org/jira/browse/CAMEL-9880
>>> should be added to the Camel 2.18.
>>>  From the proposed solutions in
>>> https://issues.apache.org/jira/browse/CAMEL-9880, I prefer  the third
>>> solution
>>> which introduces a new interface “Attachment” and methods in the Camel
>>> Message class:
>>>
>>>
>>> public interface Attachment {
>>>     DataHandler getDataHandler();
>>>
>>>     String getHeader(String name);
>>>
>>>     Collection<String> getHeaderNames();
>>>
>>>     Map<String, String> getHeaders();
>>> }
>>>
>>>
>>> Methods in the Camel Message
>>>
>>>
>>> Attachment getAttachmentObject(String id);
>>>
>>> void addAttachmentObject(String id, Attachment content);
>>>
>>> Map<String, Attachment> getAttachmentObjects();
>>>
>>> void setAttachmentObjects(Map<String, Attachment> attachments);
>>>
>>>
>>>
>>> Due to compatibility reasons we still have to support the “old” attachment
>>> methods in the Camel Message which could be marked as deprecated.
>>>
>>>
>>> Best Regards Franz
>>
>>
>>
>> --
>> 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