Skip to main content

Strange problem when deploying second web-app

  9 posts   Feedicon  
Replies: 8 - Last Post: January 14, 2014 22:01
by: MALICE
showing 1 - 9 of 9
Posted: January 02, 2014 14:44 by MALICE
Hi all,

I have recently taken over a couple of projects from a colleague and my first idea was to clean up some of the libraries he had in the project (want to switch to Maven, but need to figure out what I really need first).

I have 2 projects, both of which had java-mail in the classpath, although only 1 needs it (as far as I can tell). When I was done removing all unnecessary libs, both applications seemed to work fine when deployed separately. However, they should also work when deployed on the same server...

This is were the problem occurs... The project that needs (and has) java-mail, gives me the following exception:

javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed;

Like I said, it only does this when the other project is also deployed.

After a couple of hours of playing around, I have figured out that I can remove this exception (and have mail working again) when I add the old 'mailapi' back into the second project.

Now, the 'mailapi' isn't that big, so I could include it, but I want to know why it is necessary to put it in there at all!?

Since I am working with web-apps (on Tomcat), I thought that the libraries that are included in my WAR are not shared between applications.

Can someone shed some light on this problem and maybe point me in the right direction to remove the 'mailapi' from the second project?

My setup:
- JDK 1.6.0_38
- Tomcat 7.0.42
- mail.jar some old v.1.4, but it happens with the latest version as well
- mailapi-1.3.1.jar
Posted: January 03, 2014 22:37 by Bill Shannon
There's no version of JavaMail in any of Tomcat's lib directories, right?

If you remove mail.jar from both apps, does it fail with ClassNotFoundException?

If I understand correctly, Project #1 never uses JavaMail, and does not include mail.jar in the WEB-INF/lib directory.
Project #2 does use JavaMail, and includes mail.jar in the WEB-INF/lib directory, but it fails unless you also include
mailapi-1.3.1.jar in its WEB-INF/lib directory. Is that correct?

Does either application use JAX-WS? Does Project #1 use JAF (javax.activation) in any way?

Does mail.jar include the META-INF/mailcap file?

It does seem like there's some sort of CLASSPATH or ClassLoader issue related to the META-INF/mailcap file,
which contains the configuration for the multipart/mixed MIME type. The simplest solution might be to put mail.jar
in Tomcat's lib directory and make it available to both applications, even though only one needs it.
Posted: January 07, 2014 13:56 by MALICE
Yesterday I stumbled across this post from StackOverflow and when I read your reply, I think I might have an idea where my problem is coming from.

So, to answer your questions:

There's no version of JavaMail in any of Tomcat's lib directories, right?


Correct, JavaMail is only in the WEB-INF/lib of the project

If you remove mail.jar from both apps, does it fail with ClassNotFoundException?


P#1 runs without issues, P#2 doesn't compile (or when deleting it from the deployed app ClassNotFoundException)

If I understand correctly, Project #1 never uses JavaMail, and does not include mail.jar in the WEB-INF/lib directory.
Project #2 does use JavaMail, and includes mail.jar in the WEB-INF/lib directory, but it fails unless you also include
mailapi-1.3.1.jar in its WEB-INF/lib directory. Is that correct?


Not quite.
- P#1 does not use JavaMail and doesn't have it in WEB-INF/lib
- P#2 does use JavaMail and has it in WEB-INF/lib
When deploying them separately, everything is fine. When deploying both together, P#1 (!) needs mail-api (or mail, I guess it just needs the mailcap-settings?)

Does either application use JAX-WS? Does Project #1 use JAF (javax.activation) in any way?


Yes, P#1 uses JAX-WS.
P#1 does not have any dependencies on activation, but it did have it included (removed it because I'm using JDK6).

Does mail.jar include the META-INF/mailcap file?


Yes it does.

It does seem like there's some sort of CLASSPATH or ClassLoader issue related to the META-INF/mailcap file,
which contains the configuration for the multipart/mixed MIME type. The simplest solution might be to put mail.jar
in Tomcat's lib directory and make it available to both applications, even though only one needs it.


This works, however I am not quite happy with a solution like this. I mean, I can work with it as a developer, but for our customers it would mean having to deploy the mail.jar in TomCat manually. I would prefer to just supply customers with a WAR that has everything they need.


So, since you asked about JAX-WS right away and the SO-post I mentioned is also talking about JAX-WS, would it be better to manually set the mailcap every time I want to send a mail?
Posted: January 07, 2014 16:15 by MALICE
Update: After checking some code in JAX-WS (from the post mentioned in the entry above), I decided to put 'activation.jar' back in P#2. This seems to have solved my problem! Of course it needs some more rigorous testing, but initial tests are promising...
Posted: January 07, 2014 22:20 by Bill Shannon
When JAF is first initialized, it caches information based on the current application. This works if both JAF and JavaMail jar files are packaged with the application. It mostly works if both are are the "system classpath", as they are for Java EE application servers. But when JAF was moved into the JDK and JavaMail was not, the problem you're running into can occur. JAX-WS also uses JAF, and so Project #1 using JAX-WS is causing JAF to be initialized, but JAF doesn't see JavaMail in Project #1 and so doesn't include JavaMail configuration information.

An upcoming version of the JDK includes a JAF fix to cache the information per-application instead of globally. That should fix the problem you're running into. In the mean time, the best solution is to keep JAF and JavaMail jar files together - either both in the application or both in the system classpath.
Posted: January 14, 2014 18:53 by MALICE
Now this is getting really frustrating... After my initial tests seemed to work, I checked the updated sources back into GIT for my colleagues and QA to check it out. And guess what: The initial message is back and they are unable to send mail!

The weird part is, that I am still able to send mails on my dev-machine, but both my colleague (dev-machine) as well as QA (He uses Jenkins-built artifacts) have the same issue.

I feel like maybe the activation.jar in the Project is not being loaded and instead the one in the JDK is used... Is this at all possible? And if so, can I force it to use the JAR instead? Or is their TomCat leaking its classpath somehow?
Both are on the same TomCat version as me, although we dev's might have tweaked some stuff in out TomCat... I'll check to see if I can find any differences there...
Posted: January 14, 2014 19:21 by MALICE
Difference found! My colleague is doing a deployment similar to the QA: he builds the project and deploys the WAR to TomCat. My tests were to deploy from Eclipse using WTP. The difference is that my deployed version contains the file 'servlet-api.jar' (in both projects), which TomCat indeed notices but ignores (INFO: validateJarFile(.../servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class)

However, if I remove this JAR from both projects, I get the same issue as before: I am unable to send mail and get the message 'no object DCH for MIME type multipart/mixed'...

Any ideas why and how 'servlet-api' is influencing the projects?
Posted: January 14, 2014 20:59 by Bill Shannon
No idea. Perhaps it's just a timing issue, influencing the order in which the applications are initialized?

Including mail.jar in all applications is a simple fix. Including the META-INF/mailcap file from mail.jar in all applications is a smaller fix.
Posted: January 14, 2014 22:01 by MALICE
Including the mailcap file is enough? That indeed sounds like the smallest fix. Will try that tomorrow and if that works, I'm not touching it anymore! Wink

Thanks for the help Bill!
showing 1 - 9 of 9
Replies: 8 - Last Post: January 14, 2014 22:01
by: MALICE
 
 
Close
loading
Please Confirm
Close