You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by axelr <ar...@ordix.de> on 2013/01/03 20:49:19 UTC

MailComponent's claim to handle special mail multipart formats and attachments?!

Hi,

we are using the MailComponent to archive certain mails in a database - text
and attachments separated. Most of them are very simple and just plain text
with one or more pdf attachments.

During the last months we have got some mails where the MailComponent (esp.
its MailBinder) run into an exception:

org.apache.camel.RuntimeCamelException: Error populating the initial mail
message attachments
	at
org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:124)
	at
org.apache.camel.impl.DefaultMessage.createAttachments(DefaultMessage.java:209)
	at
org.apache.camel.impl.DefaultMessage.getAttachments(DefaultMessage.java:274)
	at xxx.BuchhaltungEmailTest.testA(BuchhaltungEmailTest.java:128)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
	at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
	at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
	at org.junit.rules.RunRules.evaluate(RunRules.java:18)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
	at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
	at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
	at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
	at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
*Caused by: javax.mail.internet.ParseException: Expected parameter value,
got "null"
	at javax.mail.internet.ParameterList.<init>(ParameterList.java:262)
	at
javax.mail.internet.ContentDisposition.<init>(ContentDisposition.java:100)
	at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:1076)
	at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:303)
	at
org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMultipart(MailBinding.java:306)
	at
org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMail(MailBinding.java:287)
	at
org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:121)
*	... 32 more

These mails are HTML emails and the result of forwarded messages containing
an attachment. They can be viewed without any problems by different mail
client (outlook, thunderbird, zarafa web access).

One of the primary reasons is the try to get the disposition and the
filename. The trace of a custom MailBinder, which catches the exceptions, is
as follows:

TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
Disposition: null
TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
Description: null
TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
ContentType: message/rfc822
TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: FileName:
null
TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: Size:
32222
TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
LineCount: -1

I am not primarily interested in a technical solution. My question is
whether Camel's MailComponent should be able to deal with such special
formats - at least without throwing an exception.
One the one hand I would say that this is more than Camel's component
can/should provide out-of-the-box. But one the other hand why should the
MailComponent fail on mails that regular mail clients are able to view (and
of course to create).
If you are of the opinion that the MailComponent should be able to deal with
(nearly) all kind of formats then I could try to provide such email and
perhaps even a jUnit test to reproduce the error.

Regards,
Axel



--
View this message in context: http://camel.465427.n5.nabble.com/MailComponent-s-claim-to-handle-special-mail-multipart-formats-and-attachments-tp5724859.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: MailComponent's claim to handle special mail multipart formats and attachments?!

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

I logged a ticket to not forget about this
https://issues.apache.org/jira/browse/CAMEL-5980


On Sun, Jan 6, 2013 at 11:25 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah I think camel-mail should be fixed to deal with this scenario.
>
> There is a ton of weird edge cases with emails.
> Feel free to log a JIRA ticket.
>
> And as always we love contributions, so patches is welcome
> http://camel.apache.org/contributing.html
>
> On Thu, Jan 3, 2013 at 8:49 PM, axelr <ar...@ordix.de> wrote:
>> Hi,
>>
>> we are using the MailComponent to archive certain mails in a database - text
>> and attachments separated. Most of them are very simple and just plain text
>> with one or more pdf attachments.
>>
>> During the last months we have got some mails where the MailComponent (esp.
>> its MailBinder) run into an exception:
>>
>> org.apache.camel.RuntimeCamelException: Error populating the initial mail
>> message attachments
>>         at
>> org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:124)
>>         at
>> org.apache.camel.impl.DefaultMessage.createAttachments(DefaultMessage.java:209)
>>         at
>> org.apache.camel.impl.DefaultMessage.getAttachments(DefaultMessage.java:274)
>>         at xxx.BuchhaltungEmailTest.testA(BuchhaltungEmailTest.java:128)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>         at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         at java.lang.reflect.Method.invoke(Method.java:601)
>>         at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>>         at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>>         at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>>         at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>>         at
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>>         at
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>>         at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
>>         at org.junit.rules.RunRules.evaluate(RunRules.java:18)
>>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>>         at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>>         at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>>         at
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>>         at
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>>         at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>>         at
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>>         at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>         at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>         at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>         at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>>         at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> *Caused by: javax.mail.internet.ParseException: Expected parameter value,
>> got "null"
>>         at javax.mail.internet.ParameterList.<init>(ParameterList.java:262)
>>         at
>> javax.mail.internet.ContentDisposition.<init>(ContentDisposition.java:100)
>>         at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:1076)
>>         at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:303)
>>         at
>> org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMultipart(MailBinding.java:306)
>>         at
>> org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMail(MailBinding.java:287)
>>         at
>> org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:121)
>> *       ... 32 more
>>
>> These mails are HTML emails and the result of forwarded messages containing
>> an attachment. They can be viewed without any problems by different mail
>> client (outlook, thunderbird, zarafa web access).
>>
>> One of the primary reasons is the try to get the disposition and the
>> filename. The trace of a custom MailBinder, which catches the exceptions, is
>> as follows:
>>
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
>> Disposition: null
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
>> Description: null
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
>> ContentType: message/rfc822
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: FileName:
>> null
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: Size:
>> 32222
>> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
>> LineCount: -1
>>
>> I am not primarily interested in a technical solution. My question is
>> whether Camel's MailComponent should be able to deal with such special
>> formats - at least without throwing an exception.
>> One the one hand I would say that this is more than Camel's component
>> can/should provide out-of-the-box. But one the other hand why should the
>> MailComponent fail on mails that regular mail clients are able to view (and
>> of course to create).
>> If you are of the opinion that the MailComponent should be able to deal with
>> (nearly) all kind of formats then I could try to provide such email and
>> perhaps even a jUnit test to reproduce the error.
>>
>> Regards,
>> Axel
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/MailComponent-s-claim-to-handle-special-mail-multipart-formats-and-attachments-tp5724859.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: MailComponent's claim to handle special mail multipart formats and attachments?!

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

Yeah I think camel-mail should be fixed to deal with this scenario.

There is a ton of weird edge cases with emails.
Feel free to log a JIRA ticket.

And as always we love contributions, so patches is welcome
http://camel.apache.org/contributing.html

On Thu, Jan 3, 2013 at 8:49 PM, axelr <ar...@ordix.de> wrote:
> Hi,
>
> we are using the MailComponent to archive certain mails in a database - text
> and attachments separated. Most of them are very simple and just plain text
> with one or more pdf attachments.
>
> During the last months we have got some mails where the MailComponent (esp.
> its MailBinder) run into an exception:
>
> org.apache.camel.RuntimeCamelException: Error populating the initial mail
> message attachments
>         at
> org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:124)
>         at
> org.apache.camel.impl.DefaultMessage.createAttachments(DefaultMessage.java:209)
>         at
> org.apache.camel.impl.DefaultMessage.getAttachments(DefaultMessage.java:274)
>         at xxx.BuchhaltungEmailTest.testA(BuchhaltungEmailTest.java:128)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:601)
>         at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>         at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>         at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>         at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>         at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>         at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>         at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
>         at org.junit.rules.RunRules.evaluate(RunRules.java:18)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>         at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>         at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>         at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>         at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>         at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>         at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>         at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>         at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>         at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>         at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> *Caused by: javax.mail.internet.ParseException: Expected parameter value,
> got "null"
>         at javax.mail.internet.ParameterList.<init>(ParameterList.java:262)
>         at
> javax.mail.internet.ContentDisposition.<init>(ContentDisposition.java:100)
>         at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:1076)
>         at javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:303)
>         at
> org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMultipart(MailBinding.java:306)
>         at
> org.apache.camel.component.mail.MailBinding.extractAttachmentsFromMail(MailBinding.java:287)
>         at
> org.apache.camel.component.mail.MailMessage.populateInitialAttachments(MailMessage.java:121)
> *       ... 32 more
>
> These mails are HTML emails and the result of forwarded messages containing
> an attachment. They can be viewed without any problems by different mail
> client (outlook, thunderbird, zarafa web access).
>
> One of the primary reasons is the try to get the disposition and the
> filename. The trace of a custom MailBinder, which catches the exceptions, is
> as follows:
>
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
> Disposition: null
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
> Description: null
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
> ContentType: message/rfc822
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: FileName:
> null
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1: Size:
> 32222
> TRACE [main] org.apache.camel.component.mail.MailBinding: Part #1:
> LineCount: -1
>
> I am not primarily interested in a technical solution. My question is
> whether Camel's MailComponent should be able to deal with such special
> formats - at least without throwing an exception.
> One the one hand I would say that this is more than Camel's component
> can/should provide out-of-the-box. But one the other hand why should the
> MailComponent fail on mails that regular mail clients are able to view (and
> of course to create).
> If you are of the opinion that the MailComponent should be able to deal with
> (nearly) all kind of formats then I could try to provide such email and
> perhaps even a jUnit test to reproduce the error.
>
> Regards,
> Axel
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/MailComponent-s-claim-to-handle-special-mail-multipart-formats-and-attachments-tp5724859.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen