camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siano, Stephan" <stephan.si...@sap.com>
Subject RE: data format for MIME-Multipart
Date Wed, 11 Nov 2015 10:28:09 GMT
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.ibsen@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.siano@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.siano@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.siano@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.ibsen@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.siano@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
Mime
View raw message