Hi Claus, No problem, I know how being busy feels. I just wanted to avoid that this is getting forgotten altogether.
I have checked the checkstyle thing (there was actually something found in the test...) About the logging in the exception cases: There are actually two cases when something is logged in the unmarshal method: 1. if the content type is taken from the "Content-Type" camel header and the content of this header cannot be parsed into a MIME content type header, the unmarshal option does not unmarshal anything (as in the case where the camel-header does not contain this header at all or the content type is not a multipart). 2. Theoretically if the MimeBodyPart instance will not give me a DataHandler (which will never happein with the current javamail implementation even though the method signature allows it). In that case the unmarshal will also return the original message. What would you propose to log in these cases? a) nothing b) some message without stack trace (on which log level)? c) log nothing but throw an exception? Best regards Stephan -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Mittwoch, 11. November 2015 09:44 To: dev <dev@camel.apache.org> Subject: Re: data format for MIME-Multipart Hi Sorry but it seems people are busy with day time jobs. It does take more time to review an entire new component. Also we are focusing on getting a 2.16.1 release out with the needed bug fixes. At first glance there seems to be room for improving the exception handling. We do not want to have big WARNs with long stacktraces, or INFO logging etc, which happens in the unmarshal operation. Either fail fast, or do not be noisy. Also a good idea is to ensure the checkstyle passes. See how to run with that at: http://camel.apache.org/building.html Otherwise it seems likely good. I put it on the roadmap for next 2.17 release. Are you able to work on documentation as well? Are you able to edit the wiki directly? On Wed, Nov 11, 2015 at 8:53 AM, Siano, Stephan <stephan.si...@sap.com> wrote: > Hi, > > Sorry for nagging but I haven't received any feedback so far. Is the patch in > the JIRA task ok or is there something wrong with it? > > Best regards > Stephan > > -----Original Message----- > From: Siano, Stephan [mailto:stephan.si...@sap.com] > Sent: Montag, 2. November 2015 17:00 > To: dev@camel.apache.org > Subject: RE: data format for MIME-Multipart > > Hi Claus, > > I have created https://issues.apache.org/jira/browse/CAMEL-9283 for it. > > Best regards > Stephan > > -----Original Message----- > From: Siano, Stephan [mailto:stephan.si...@sap.com] > Sent: Montag, 2. November 2015 12:55 > To: dev@camel.apache.org > Subject: RE: data format for MIME-Multipart > > Hi Claus, > > The called library used for this mime-parsing/marshalling is javamail (though > the javax activation stuff is also involved but this is exactly the same as > in the mail endpoints). The footprint of the required class is definitely > small... > > I will prepare the contribution. > > Adding a data format means also to add some stuff to camel-core for Java/XML > (Spring/Blueprint) DSL. Is there some documentation about the details. Is > there something else to consider? > > Best regards > Stephan > > -----Original Message----- > From: Claus Ibsen [mailto:claus.ib...@gmail.com] > Sent: Samstag, 31. Oktober 2015 09:00 > To: dev > Subject: Re: data format for MIME-Multipart > > Hi > > Yeah sounds good. We do have some camel artifacts that include both a > regular camel component and data format. Though usually if they do the > same. > > Since the added code does not add in more dependencies I am okay with > adding that to camel-mail. As you say the MIME stuff are in those > libraries? Or in the javax activation or what its called? > > And the added code is small so the increased size of the JAR is not > noticeable. > > And maybe there can be some shared code between the data format and > the current mail component. > > Just hack on the code and when you are ready then you know how to contribute. > http://camel.apache.org/contributing > > On Mon, Oct 26, 2015 at 2:51 PM, Siano, Stephan <stephan.si...@sap.com> wrote: >> Hi, >> >> I have written a data format that can convert a Camel message with >> attachments into a Camel message having a MIME-Multipart message as message >> body (and no attachments). The use case for this is to enable the user to >> send attachments over endpoints that do not directly support attachments, >> either as special protocol implementation (e.g. send a MIME-multipart over >> an HTTP endpoint) or as a kind of tunneling solution (e.g. because camel-jms >> does not support attachments but by marshalling the message with attachments >> into a MIME-Multipart, sending that to a JMS queue, Receiving the message >> from the JMS queue and unmarshalling it again (into a message body with >> attachments). >> >> Do you think this data format is worth contributing? >> >> I would propose to contribute it to camel-mail even though it is not exactly >> mail related. However I use javamail as a dependency, so the data format >> shares all dependencies with the camel-mail component. Do you think this is >> ok, or should I create a new component for it? >> >> Best regards >> Stephan > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2nd edition: > https://www.manning.com/books/camel-in-action-second-edition -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
