Repository navigation
[JENKINS-1261] Fatal exception when sending mail : java.lang.ClassCastException: gnu.mail.handler.TextPlain #437
Description
When a build finishes, hudson fails to send a mail with the result of the build.
This behaviour is new to version 1.180 (it worked with version 1.179).
We get the following trace (note there is a valid e-mail and an invalid one,
that's maybe the cause):
Sending e-mails to: valid@email.Com ipad7251orange-ftgroup.com
FATAL: gnu.mail.handler.TextPlain
java.lang.ClassCastException: gnu.mail.handler.TextPlain
at
javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:596)
at
javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:550)
at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:611)
at javax.activation.DataHandler.writeTo(DataHandler.java:315)
at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:248)
at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1268)
at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2012)
at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:1980)
at javax.mail.Transport.send(Transport.java:97)
at hudson.tasks.MailSender.execute(MailSender.java:74)
at hudson.tasks.Mailer._perform(Mailer.java:75)
at hudson.tasks.Mailer.perform(Mailer.java:69)
at
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:33)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:273)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:261)
at hudson.model.Build$RunnerImpl.post2(Build.java:136)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:246)
at hudson.model.Run.run(Run.java:677)
at hudson.model.Build.run(Build.java:101)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:65)
Thanks.
Originally reported by julienw, imported from: Fatal exception when sending mail : java.lang.ClassCastException: gnu.mail.handler.TextPlain
- status: Closed
- priority: Critical
- component(s): mailer-plugin
- resolution: Fixed
- resolved: 2009-08-31T19:06:50+00:00
- votes: 0
- watchers: 0
- imported: 20251211-223321
Raw content of original issue
When a build finishes, hudson fails to send a mail with the result of the build. This behaviour is new to version 1.180 (it worked with version 1.179).
We get the following trace (note there is a valid e-mail and an invalid one, that's maybe the cause):
Sending e-mails to: valid@email.Com ipad7251orange-ftgroup.com FATAL: gnu.mail.handler.TextPlain java.lang.ClassCastException: gnu.mail.handler.TextPlain at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:596) at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:550) at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:611) at javax.activation.DataHandler.writeTo(DataHandler.java:315) at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:248) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1268) at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2012) at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:1980) at javax.mail.Transport.send(Transport.java:97) at hudson.tasks.MailSender.execute(MailSender.java:74) at hudson.tasks.Mailer._perform(Mailer.java:75) at hudson.tasks.Mailer.perform(Mailer.java:69) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:33) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:273) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:261) at hudson.model.Build$RunnerImpl.post2(Build.java:136) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:246) at hudson.model.Run.run(Run.java:677) at hudson.model.Build.run(Build.java:101) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:65)
Thanks.
- environment:
Platform: All, OS: All
Activity
jenkins-infra-bot commentedon Feb 10, 2008
Raw content of original comment:
Can you tell me a bit more about your environment?
What container do you run this on? OS?
jenkins-infra-bot commentedon Feb 11, 2008
julienw:
Raw content of original comment:
We're using JRockIt R26.4.0 (based on Sun JDK 1.5.0_06), on JOnAS 4.8.4.
To be able to install Hudson on JOnAS we added a file jonas-web.xml in hudson's
this file must have:
WEB-INF directory, I'll open a separate issue for this
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.objectweb.org/jonas/ns
http://www.objectweb.org/jonas/ns/jonas-web-app_4_0.xsd" >
false
jenkins-infra-bot commentedon Feb 11, 2008
julienw:
Raw content of original comment:
I tried to remove mail-1.4.jar and activation-1.1.jar from the WAR file, and it
worked.
Yet I don't know how you could make this a default...
jenkins-infra-bot commentedon Feb 11, 2008
julienw:
Raw content of original comment:
Some explanations about my last comment :
we found that JOnAS uses the GNU implementation for javamail API and the
activation framework. GNU Java Mail implements version 1.3 of the API whereas
the implementation that hudson uses implements version 1.4 of the API.
Maybe that's the reason...
jenkins-infra-bot commentedon Feb 27, 2008
Raw content of original comment:
Perhaps false is wrong? This
seems like forcing JONAS to load javamail from Hudson, not from JONAS itself.
jenkins-infra-bot commentedon Feb 27, 2008
julienw:
Raw content of original comment:
If you don't use this, asm is loaded from JOnAS... which is rather old.
Indeed I think this has something to do with classloaders. But just deleting
javamail and activation jars from Hudson's war makes Hudson use the jars in
JOnAS, and it works correctly.
jenkins-infra-bot commentedon Mar 17, 2008
julienw:
Raw content of original comment:
For information, I found that the bug is also in JOnAS' bugtracker (in french
):
http://forge.objectweb.org/tracker/index.php?func=detail&aid=308797&group_id=5&atid=100005
jenkins-infra-bot commentedon Aug 8, 2008
Raw content of original comment:
Filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=5452 to fix
activation.jar to handle this more gracefully.
Hudson can then bundle such activation.jar to fix this problem.
jenkins-infra-bot commentedon Oct 28, 2008
xaviou:
Raw content of original comment:
I have exactly the same issue on Tomcat 5.5.23 packaged for Fedora 6.
I use Hudson 1.256, and I have this issue since I use Hudson (version 1.244).
As julienw suggested, I removed the mail and activation jars, and now it works.
jenkins-infra-bot commentedon Mar 2, 2009
sauthieg:
Raw content of original comment:
I've update the JOnAS' tracker comment.
In substance: if the ASM dependency of hudson (or of the hudson's component
that's really using ASM) could be removed, the delegation model could be set to
false (meaning ask parent first).
So the question become: is this possible to remove this dependency ? Jarjar or
the maven-shade-plugin could be used to automatically "privatize" the ASM
version in use.
What do you think ?
jenkins-infra-bot commentedon Jul 9, 2009
Raw content of original comment:
Given the presence of the work around, re-prioritizing.
I continue to believe that a better fix is a patched activation.jar. Fiddling
with classloader loader priority can very easily cause some other things to break.
jenkins-infra-bot commentedon Aug 31, 2009
Raw content of original comment:
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/pom.xml
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=21316
Log:
[FIXED JENKINS-1261] Bundling the patched activation.jar that fixes the ClassCastException problem.