Sending Email

[Carl F. Hall]

I'm finishing some full cycle email testing and have hit a problem. Whenever the code tries to connect to the mail server and deliver the message, the exception below is thrown. This seems like a classloading issue to me as the definition of the DCH to use for text/plain is defined in the javax activation jar in META-INF/mailcap.default. Any thoughts from the audience?

Sending the email to the following server failed : localhost:25 org.apache.commons.mail.EmailException: Sending the email to the following server failed : localhost:25
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1138)
at org.apache.commons.mail.Email.send(Email.java:1163)
at org.sakaiproject.kernel.email.outgoing.OutgoingEmailMessageListener.onMessage(OutgoingEmailMessageListener.java:158)
at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1021)
at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:122)
at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:192)
at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type text/plain
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:625)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:98)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1128)
... 10 more
Caused by: javax.activation.UnsupportedDataTypeException: no object DCH for MIME type text/plain
at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:885)
at javax.activation.DataHandler.writeTo(DataHandler.java:316)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1350)
at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1683)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:585)
... 13 more

[Ian Boston]

On 26 Oct 2009, at 19:43, Carl F. Hall wrote:

>
> I'm finishing some full cycle email testing and have hit a problem.
> Whenever the code tries to connect to the mail server and deliver
> the message, the exception below is thrown. This seems like a
> classloading issue to me as the definition of the DCH to use for
> text/plain is defined in the javax activation jar in META-INF/
> mailcap.default. Any thoughts from the audience?

Yes, classloading,

At some point the code will do something like
classloader.getResource("META-INF/mailcap.default") or
classloader.getResourceAsStream("META-INF/mailcap.default")

I think we may need some MANIFEST.MF directives to load resources
correctly from a jar where the loading class has been exported or...
we need to embed activation.jar inside the mail sending bundle allong
with mail.jar

I think it might be worth reading the OSGi spec on resources, and
having a look for BND directives in the resources area.

Ian

[Carl F. Hall]

----- "Ian Boston" <i...@tfd.co.uk> wrote:

> On 26 Oct 2009, at 19:43, Carl F. Hall wrote:
>
> >
> > I'm finishing some full cycle email testing and have hit a problem.
>
> > Whenever the code tries to connect to the mail server and deliver
> > the message, the exception below is thrown. This seems like a
> > classloading issue to me as the definition of the DCH to use for
> > text/plain is defined in the javax activation jar in META-INF/
> > mailcap.default. Any thoughts from the audience?
>
>
> Yes, classloading,
>
> At some point the code will do something like
> classloader.getResource("META-INF/mailcap.default") or
> classloader.getResourceAsStream("META-INF/mailcap.default")
>
> I think we may need some MANIFEST.MF directives to load resources
> correctly from a jar where the loading class has been exported or...
>
> we need to embed activation.jar inside the mail sending bundle allong
>
> with mail.jar
>
> I think it might be worth reading the OSGi spec on resources, and
> having a look for BND directives in the resources area.
>
> Ian

This matches other things I've found [1]. I've found the code that does the loading of mailcap files and it's definitely a classloader issue.

We /could/ embed activation.jar in the mail bundle but a few other bundles use the activation bundle. I think it's best to leave this bundle separate and get the class/resource sharing fixed.

[1] http://forums.sun.com/thread.jspa?threadID=5353050

[Ian Boston]

On 26 Oct 2009, at 21:19, Carl F. Hall wrote:

>
> This matches other things I've found [1]. I've found the code that
> does the loading of mailcap files and it's definitely a classloader
> issue.
>
> We /could/ embed activation.jar in the mail bundle but a few other
> bundles use the activation bundle. I think it's best to leave this
> bundle separate and get the class/resource sharing fixed.
>
> [1] http://forums.sun.com/thread.jspa?threadID=5353050

WT* is Eclipse-BuddyPolicy?
That sounds like a Equinox only hack..... yuck!

I hope there is a generic alternative. I wouldnt want to have to put a
hack in for each OSGi container.

I notice that the activation in this instance is a Spring DM modified
bundle as well.

"
However, editing the manifest.mf file of the activation bundle and
providing a "Eclipse-BuddyPolicy: registered" line as well as a
"Eclipse-RegisterBuddy: com.springsource.javax.activation" to the mail
bundle solved the problem.
"

[carl...@et.gatech.edu]

The manifest header they refer to (Eclipse-BuddyPolicy) was supposed to make it into 4.1 but I can't find any mention of it in the spec docs (core or compendium). So, it seems to be an Equinox specific header and no use to us. Even if we could use it, it would mean we have to wire the activation bundle to other bundles that it needs to read (parent looking for specific, known children) which is backwards of the OSGi way of registering services (any children reporting to parent) which will be a maintenance headache.

I'm looking more into the activation code to see if we can load mailcap files programmatically. I believe I've found a way to add
them from bundles as the bundle is activated but I need to find a way to remove them if the bundle is deactivated.

I believe that the spring bundle mentioned is just a spring wrapper on the javax.activation stuff like we're doing. I'm going to pull the bundle apart to see if there are any other things to be learned from it.

I hope to have more to report tomorrow. All suggestions are welcome.

----- "Ian Boston" <i...@tfd.co.uk> wrote:

[Ian Boston]

Ok, Im going to ask sling dev, just in case anyone has seen this
before with Felix, there was talk in 2005 and 2008, but the opinion
was not to do anything until its in the spec.

2 things to look at.

1. Put mail and activation in the same bundle.
2. I think there is a context classloader used here, otherwise the
activation class would see its own resources, any ideas when that
context classloader gets attached ?

Ian

[Carl F. Hall]

----- "Ian Boston" <i...@tfd.co.uk> wrote:

> Ok, Im going to ask sling dev, just in case anyone has seen this
> before with Felix, there was talk in 2005 and 2008, but the opinion
> was not to do anything until its in the spec.
>
> 2 things to look at.
>
> 1. Put mail and activation in the same bundle.
> 2. I think there is a context classloader used here, otherwise the
> activation class would see its own resources, any ideas when that
> context classloader gets attached ?

In activation:
Command.getDefaultCommandMap() creates a new MailcapCommandMap. The constructor for that loads all the mailcap and the resulting object is reused statically for its life. I'm not exactly sure when this gets called the first time but will watch for it in the debugger tomorrow.

[Ian Boston]

On 26 Oct 2009, at 21:53, Carl F. Hall wrote:

>
>
> ----- "Ian Boston" <i...@tfd.co.uk> wrote:
>
>> Ok, Im going to ask sling dev, just in case anyone has seen this
>> before with Felix, there was talk in 2005 and 2008, but the opinion
>> was not to do anything until its in the spec.
>>
>> 2 things to look at.
>>
>> 1. Put mail and activation in the same bundle.
>> 2. I think there is a context classloader used here, otherwise the
>> activation class would see its own resources, any ideas when that
>> context classloader gets attached ?
>
> In activation:
> Command.getDefaultCommandMap() creates a new MailcapCommandMap. The
> constructor for that loads all the mailcap and the resulting object
> is reused statically for its life. I'm not exactly sure when this
> gets called the first time but will watch for it in the debugger
> tomorrow.

Hmm,
you could add an activator inside the javax.activation bundle that
causes the static loading ?

Ian

[Carl F. Hall]

After the conversation on the Sling list and looking again at the inherent ties between activation and mail (activation looks for mail specific files), I'm going to merge the 2 bundles and export the same packages as the 2 bundles exported independently. If we run into this issue with another bundle, I'll review the situation then.

On a side note, I did try updating mail to 1.4.1 & 1.4.2 yesterday with horrible failure. mail;version>=1.4.1 has ties to sun.security.util and others which are problematic as these packages are part of the JDK and rightly not exported by the system bundle. There might be another workaround but for now, I'm sticking with mail 1.4 and activation 1.1.

[Ian Boston]

On 27 Oct 2009, at 12:08, Carl F. Hall wrote:

>
> After the conversation on the Sling list and looking again at the
> inherent ties between activation and mail (activation looks for mail
> specific files), I'm going to merge the 2 bundles and export the
> same packages as the 2 bundles exported independently. If we run
> into this issue with another bundle, I'll review the situation then.
>
> On a side note, I did try updating mail to 1.4.1 & 1.4.2 yesterday
> with horrible failure. mail;version>=1.4.1 has ties to
> sun.security.util and others which are problematic as these packages
> are part of the JDK and rightly not exported by the system bundle.
> There might be another workaround but for now, I'm sticking with
> mail 1.4 and activation 1.1.

you should be able to say something like
sun.*;resolution:=optional
or
sun.*;resolution:=dynamic

IIRC The fact that javax.mail binds to sun.* is really bad as it means
it wont work on non sun JVM's. Is that correct ?

[Carl F. Hall]

----- "Ian Boston" <i...@tfd.co.uk> wrote:
>On 27 Oct 2009, at 12:08, Carl F. Hall wrote:
>
>>
>> After the conversation on the Sling list and looking again at the
>> inherent ties between activation and mail (activation looks for mail
>
>> specific files), I'm going to merge the 2 bundles and export the
>> same packages as the 2 bundles exported independently. If we run
>> into this issue with another bundle, I'll review the situation then.
>>
>> On a side note, I did try updating mail to 1.4.1 & 1.4.2 yesterday
>
>> with horrible failure. mail;version>=1.4.1 has ties to
>> sun.security.util and others which are problematic as these packages
>
>> are part of the JDK and rightly not exported by the system bundle.
>
>> There might be another workaround but for now, I'm sticking with
>> mail 1.4 and activation 1.1.
>
>you should be able to say something like
>sun.*;resolution:=optional
>or
>sun.*;resolution:=dynamic
>
>IIRC The fact that javax.mail binds to sun.* is really bad as it means
>
>it wont work on non sun JVM's. Is that correct ?

I'll try making optional the sun.security.* bits and report back. This type of binding does worry me that javax.mail won't work on other JVM's which seems like a really bad move on Sun's part.

[Carl F. Hall]

I've merged activation and mail to form (wait for it), activation-mail. I was able to test sending email and verify it via email server logs. No more exceptions and all other bundles that needed activation or mail are properly resolving to this unified bundle. This has all been pushed to my git repo.

I'll try upgrading to newer versions for activation and mail but don't expect a lot of success. More news as it happens.

[Carl F. Hall]

I have, to my surprise, been able to get activation-1.1.1 and mail-1.4.2 to play nice in OSGi. Adding sun.security.util;resolution:=optional to Import-Package worked for this. I was hesitant to do this until I read through the javamail code and found that they use reflection to pick up sun.security.util and do not rely on it.

I found someone else that ran into this and responded to their forum post [1]. I give it again here to help spread the word.

[1] http://forums.sun.com/thread.jspa?messageID=10849184&#10849184

[Ian Boston]

Hey, well done, this is fantastic.

I will merge asap.
Ian