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.si...@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:emc2...@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.a...@xison.com>"; > type="Application/X-FixedRecord" > start-info="-o ps" > > --example-1 > Content-Type: Application/X-FixedRecord > Content-ID: <950120.a...@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.a...@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: st...@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
