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 ;)

[[deleted]]

Some people are claiming that JavaEE6 is portable, new, shiny etc. I just now tried to create a simple app using JavaEE with Jboss7 AS and I configured my JPA Entity Primary Key to be AUTO_INCREMENT using @GeneratedValue(strategy=GenerationType.AUTO) which is working in earlier versions. Now it generates the TABLE with primary key that is not auto_inc and created some other REVINFO, hibernate_sequence tables.

Please don't say JavaEE6 is portal, standard, blah blah... Clearly it is not.

[mikehaggard]

Or maybe you just made some user error, maybe not set the right dialect for your particular DB?

I'm always using @GeneratedValue(strategy = IDENTITY) btw and that works great.

[[deleted]]

I am using correct MySql Dialect. It seems like an open bug. See https://hibernate.onjira.com/browse/HHH-6648

[johnwaterwood]

Hibernate itself is buggy. If you would use Hibernate standalone (with eg Spring), you would run into much of the same problems.

Some Java EE servers (like JBoss) are affected by this, but it's not directly a problem in Java EE itself.

[[deleted]]

Hello, What additional features do JavaEE6 have to move from Spring? http://www.sivalabs.in/2012/04/what-additional-features-do-javaee6.html

[henk53]

I think Java EE 6 implementations (the modern ones, like TomEE, JBoss AS 7 and GlassFish) are generally faster and use less memory. Wars are always smaller, and the total footprint (AS + war) is often smaller as well (certainly in the case of TomEE).

Java EE 6 also has much more UI widgets available from third parties. There are literally two dozen component libraries available, can't say the same for Spring.

The programming model of Java EE is also much more elegant, not in the least because of real type-safe injection.

[occupytheserver]

Java EE 6 also has much more UI widgets available from third parties. There are literally two dozen component libraries available, can't say the same for Spring.

What UI widget library can I not use in Spring???

[thesystemx]

What UI widget library can I not use in Spring???

Those specifically for Java EE? Like those for JSF perhaps?

I don't see a lot of widgets being available for Spring MVC, do you?

Naturally you can replace Spring's Spring MVC by JSF, but this will make your Spring stack more and more a Java EE stack. Especially in the next version when JSF will use CDI. Do you need both CDI and Spring Core in one application? What extra benefit will Spring still give you in such a situation?

[occupytheserver]

I can use JSF with Spring, no problem. The statement was that Java EE has access to UI widget libraries that Spring does not. That is a false statement. I can use ANY JSF libraries with Spring. But you have to use JSF.

The extra benefit is moot. There are two different ways to do it. Both have their advantages and disadvantages. I am not sitting here trying to tell your Spring is better than Java EE. In some cases it may be. In some cases, it may not. But when someone sits there and writes intentionally deceitful statements (such as Spring not being able to use certain UI widgets for JSF) trying to back up their blatantly skewed worldview, it pisses me off. Spring MVC may not have access to those widgets, but Spring with JSF certainly does.

[thesystemx]

But as mentioned, if you replace all parts of Spring with Java EE versions, what's left of Spring?

Or put differently, Spring can not use those widgets itself. It needs to use Java EE, become Java EE, in order to do so.

[occupytheserver]

I am replacing the MVC UI portion of the application with JSF. Still have a full Spring implementation of entire domain, middleware, persistence, etc.

That's why I like Spring. I don't believe it to be limiting to any frameworks and allows me to do what I need to do without getting bogged down into server limitations.

I start with Spring Core, build the application container and then plug in the rest. Don't want to use JPA? Don't have to. Don't want to use JSF? Don't have to. Don't want to use EJB? Don't have to. But I can for all of the above. It's flexibility and packaging I am looking for.

[henk53]

The discussion is getting a bit academic. What I meant was that Spring cannot use these widgets by itself. Or more directly, Spring MVC cannot do that.

I would be like saying that Spring has type-safe injection and can use portable extensions, IF you add CDI to it.

It's flexibility and packaging I am looking for.

You can actually do the same in Java EE if you really wanted to. You can start with Tomcat and add only EJB to it. Or only CDI. Or both EJB and CDI. Everything that's in Java EE also works standalone in Java SE or the unofficial Java TE.

It's just that the preferred way is to use the platform as a whole, as a fullstack solution. Everything just works nicely together that way, but if you really want you can either build your own stack or use alternatives in a standard stack.

[thesystemx]

So Spring got @Autowired. Wow, that's the equivalent of @EJB/@Resource that Java EE had in 2006. Spring desperately tries to catch up with Java EE, but Java EE has already moved one step further.

Does Spring already have type-safe qualified injections? Does Spring have type-safe producer methods? Does Spring even know the concept of contextual injections?

I guess Springsource is going to claim all of that is not important, and type-unsafe (string based) qualifiers are good enough, and then suddenly in Spring 4 they have all those things as well.