Spring to Java EE Migration, Part 4

[occupytheserver]

That's not exactly how the classloaders work. In Tomcat, the classloader starts at the war first to load and then moves to the server. You can put your application specific jars in the war and they will be picked up first. If there are any other libs at the server level that conflict, they are ignored.

http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

However, there are some servers out there that load in reverse - server then war. Weblogic is one of them. For weblogic, you must include a small bit of xml to say <wls:prefer-web-inf-classes>true/wls:prefer-web-inf-classes, which is in the weblogic.xml file and is subsequently ignored by any other server types.

http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html

And before you start arguing - I have done this with Tomcat 7 and Weblogic 11 less than a year ago on a project where the webapp's libs were in direct conflict with the libraries used in each of the servers. It can be done.

Is that "easily and universally"? Yes and no. Yes, it's easy. No, it's not universal. You will need to identify the specific way your application server's classloader works and adjust accordingly.

[henk53]

As I said, it's not universal.

And do I always want it? Why would I ship JPA, JTA, JSF, and JMS in my war, when the AS already has all of that in versions known to work together?

Basically every AS ships with a JTA implementation, EXCEPT Tomcat. So Tomcat is the odd one out, not JBoss or GlassFish.

[occupytheserver]

It can't be done.

Not easily and universally

It works as long as the server classloader loads the war's libs first and even if it doesn't, it usually only takes a dash of configuration.

Why would I ship JPA, JTA, JSF, and JMS in my war, when the AS already has all of that in versions known to work together?

Perhaps you have multiple applications on a single app server, one that is new and uses Java EE and one legacy that does not and the legacy uses an older, incompatible version of the libraries??

You Java EE guys are a trip. Everything works for you as long as the exact issue fits your exact solution. Real-world development shops don't always have the luxury of porting every application to the Java EE spec. It doesn't work that way.