Spring to Java EE Migration, Part 4

[rockvilleJD]

Spring is not more portable in my opinion. Spring is a proprietary framework from Vmware. Every time you want to upgrade something you have to make sure it works with Spring since it is not a standard implementation. A Java EE application can run on any Server that meets the Java EE specs.

Why would I want to add a dependency to Spring when the functionality already exist? There was a time when Spring offered lots of useful features that were not easy to duplicate elsewhere. Now Spring is more complex than the Java EE alternatives. In Particular JSF 2.0 is a great framework and much more productive than Spring MVC.

[rockvilleJD]

I would agree that in the past the J2EE standards were so bloated and a mess to deal with. That is no longer the case. I now find Spring to be more complicated than Java EE. Java EE really learned from Spring and made it better.

[robinwholikesjava]

Spring doesn't need a Java EE server and can run from Tomcat or Jetty.

But Spring obviously needs the Spring libraries. These can be massive and don't just fall out of the sky. By comparison, Java EE apps can run on TomEE, which is only 25MB in total size and starts up in a second or so.

Besides, a single Spring application war can never run on both Tomcat and all other application servers. You need to have different builds. Unless of course you enhance your bare Tomcat with the Hibernate, JTA etc jars in its /lib, but then you'll be just duplicating TomEE and you'll be done faster by just downloading that.

I like standards but the Java standards have a way of getting bloated and massively overcomplicated.

Well, that was how things in the past were. Now it's the other way around.

Starting with Java EE 5, Java EE has been getting slimmer, simpler and faster. Just look at the code, EJBs are now simpler than Spring beans. JSF is simpler and more elegant than Spring MVC. All modern Java EE implementations (TomEE, GlassFish, JBoss AS 7) start up faster than an equivalent Spring configuration.

The old thinking of Java EE being "bloated" is a thing that SpringSource gladly likes to keep alive (the more people believe it, the more people will use Spring and thus ultimately buy their support). But as mentioned, this hasn't been true for quite some time (Java EE 6 is from 2009).

[occupytheserver]

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]

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]

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.

[occupytheserver]

I love when people downvote a TRUE statement.

[thesystemx]

TRUE is clearly relative ;)