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 <dev@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.ib...@gmail.com] Sent: Tuesday, July 19, 2016 3:26 PM 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.si...@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.ib...@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.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+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
