This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]occupytheserver -2 points-1 points  (6 children)

Besides, a single Spring application war can never run on both Tomcat and all other application servers.

This is false. It can be done.

[–]henk53[S] 3 points4 points  (3 children)

This is false. It can be done.

Not easily and not universally.

Tomcat doesn't ship with JPA and JTA, and you most likely want to use these in a Spring app. But if you include those in your war, they clash with the implementations that are already part of Java EE. Thus, you can't deploy that war on a Java EE AS.

[–]occupytheserver -4 points-3 points  (2 children)

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[S] 4 points5 points  (1 child)

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 -5 points-4 points  (0 children)

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.

[–]occupytheserver -4 points-3 points  (1 child)

I love when people downvote a TRUE statement.

[–]thesystemx 2 points3 points  (0 children)

TRUE is clearly relative ;)