You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Franz Paul Forsthofer <em...@googlemail.com> on 2016/07/07 12:39:51 UTC
[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="<95...@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <95...@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: <95...@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 <la...@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
RE: [DISCUSS] Attachment Headers
Posted by Bharath Kumar Champalal <Bh...@mindtree.com>.
That would be gr8.
Can we have Doxygen as an option
They support Markdown, which looks nice.
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Tuesday, July 19, 2016 3:26 PM
To: dev <de...@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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>> type="Application/X-FixedRecord"
>> start-info="-o ps"
>>
>> --example-1
>> Content-Type: Application/X-FixedRecord
>> Content-ID: <95...@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: <95...@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 <la...@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+2bQAAACQAAAAASEgAAAAkSEgkJG0kJJEkAABIkZFIJCRtt
>> R0lGODdhQAHIAKMAAAAAAP+rZt
>> 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
________________________________
http://www.mindtree.com/email/disclaimer.html
RE: [DISCUSS] Attachment Headers
Posted by "Siano, Stephan" <st...@sap.com>.
Thanks for the pointer.
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Dienstag, 19. Juli 2016 13:08
To: dev <de...@camel.apache.org>
Subject: Re: [DISCUSS] Attachment Headers
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 <st...@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 <de...@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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>>> type="Application/X-FixedRecord"
>>> start-info="-o ps"
>>>
>>> --example-1
>>> Content-Type: Application/X-FixedRecord
>>> Content-ID: <95...@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: <95...@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 <la...@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
Re: [DISCUSS] Attachment Headers
Posted by Claus Ibsen <cl...@gmail.com>.
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 <st...@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 <de...@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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>>> type="Application/X-FixedRecord"
>>> start-info="-o ps"
>>>
>>> --example-1
>>> Content-Type: Application/X-FixedRecord
>>> Content-ID: <95...@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: <95...@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 <la...@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
RE: [DISCUSS] Attachment Headers
Posted by "Siano, Stephan" <st...@sap.com>.
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 <de...@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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>> type="Application/X-FixedRecord"
>> start-info="-o ps"
>>
>> --example-1
>> Content-Type: Application/X-FixedRecord
>> Content-ID: <95...@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: <95...@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 <la...@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
RE: [DISCUSS] Attachment Headers
Posted by Bharath Kumar Champalal <Bh...@mindtree.com>.
That can be done in GIthub too. Since that supports.
-----Original Message-----
From: Bharath Kumar Champalal
Sent: Tuesday, July 19, 2016 3:39 PM
To: dev <de...@camel.apache.org>
Subject: RE: [DISCUSS] Attachment Headers
That would be gr8.
Can we have Doxygen as an option
They support Markdown, which looks nice.
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Tuesday, July 19, 2016 3:26 PM
To: dev <de...@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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>> type="Application/X-FixedRecord"
>> start-info="-o ps"
>>
>> --example-1
>> Content-Type: Application/X-FixedRecord
>> Content-ID: <95...@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: <95...@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 <la...@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+2bQAAACQAAAAASEgAAAAkSEgkJG0kJJEkAABIkZFIJCRtt
>> R0lGODdhQAHIAKMAAAAAAP+rZt
>> 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
________________________________
http://www.mindtree.com/email/disclaimer.html
Re: [DISCUSS] Attachment Headers
Posted by Claus Ibsen <cl...@gmail.com>.
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 <st...@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 <de...@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 <st...@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="<95...@XIson.com>";
>> type="Application/X-FixedRecord"
>> start-info="-o ps"
>>
>> --example-1
>> Content-Type: Application/X-FixedRecord
>> Content-ID: <95...@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: <95...@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 <la...@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
RE: [DISCUSS] Attachment Headers
Posted by "Siano, Stephan" <st...@sap.com>.
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 <de...@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 <st...@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="<95...@XIson.com>";
> type="Application/X-FixedRecord"
> start-info="-o ps"
>
> --example-1
> Content-Type: Application/X-FixedRecord
> Content-ID: <95...@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: <95...@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 <la...@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
Re: [DISCUSS] Attachment Headers
Posted by Claus Ibsen <cl...@gmail.com>.
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 <st...@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="<95...@XIson.com>";
> type="Application/X-FixedRecord"
> start-info="-o ps"
>
> --example-1
> Content-Type: Application/X-FixedRecord
> Content-ID: <95...@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: <95...@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 <la...@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
RE: [DISCUSS] Attachment Headers
Posted by "Siano, Stephan" <st...@sap.com>.
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="<95...@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <95...@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: <95...@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 <la...@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