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 07:53:31 GMT
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
Mime
View raw message