Blogs

SpringSource Blog

Spring 3 on a Java EE 6 server

Juergen Hoeller

Spring on Java EE 6 – a viable combination? Can you easily continue to use Spring when you have a Java EE 6 server to deploy to? At this year's edition of the SpringOne conference which kicked off just a few hours ago, I'll once again be presenting a session on Spring and EE 6: now with a focus on GlassFish 3 as an actually available (and at this point, still the only available) EE 6 server for production environments. As a sneak preview, here are four key considerations taken from that presentation…

1. A Java EE 6 server like GlassFish 3 is a fine runtime environment for Spring 3

GlassFish 3 provides a lot of out-of-the-box middleware: Servlet 3.0, JSF 2.0, JPA 2.0, as well as traditional EE services such as JTA and JMS – all ideally suited for use in Spring-based applications. GlassFish also bundles a JSR-303 validation provider, the JSR-330 API, the JSR-250 common annotations: key APIs for use with Spring 3.0 as well. With such a combination, the overlap of Spring as a framework and the server as a middleware platform is minimal: basically just the EJB and CDI component models (constituting about 5% of the GlassFish 3 codebase only) which Spring provides an alternative programming model for, while integrating with the very same platform services underneath.

2. Choosing Spring is a completely natural thing to do even on a Java EE 6 server

On GlassFish 3, a lot of developers will continue to choose e.g. Wicket or GWT over JSF, Hibernate over EclipseLink, as well as Spring over EJB/CDI. Those decisions will be driven by style considerations as well as architectural requirements, and not least of it all by portability concerns. All of those frameworks have to be deployed along with the application since they are not a core part of the server, but that is hardly going to be a decisive factor. FWIW, they are even in the same ballpark in terms of "weight": Compare the size of the Hibernate 3.6 jars with those of Spring 3.0 (~4 MB).

3. Are you willing to constrain your target environments to Java EE 6 servers?

Only GlassFish 3 is available as a final version today. JBoss 6 is still in milestone 5; WebSphere 8 is in early beta. Spring 3, on the other hand, runs on Tomcat 5, 6 and 7, as well as on J2EE 1.4 servers such as WebSphere 6.1, as well as on Java EE 5 servers such as WebSphere 7. And if an EE 6 server happens to be around in production, then Spring 3 is a "Good Citizen" and will be using as much EE 6 server functionality as possible. Beyond that, Spring 3 based applications can be deployed onto cloud platforms such as Google App Engine and VMforce…

4. The world is evolving beyond Java EE 6 and, foreseeably, also beyond Java EE 7

See clouds, see NoSQL, see distributed caches… The Java EE 6 specs capture the state of the art in early 2009 – and so does Spring 3.0. However, since the release of EE 6, alternative trends moved to the front row. Spring 3.1/3.2 will be evolving towards that direction in the course of 2011: Brand-new programming model features will be available for immediate use on existing deployment platforms (be it e.g. Tomcat 6 or WebSphere 7, with no need to go through a server upgrade). With this inherent agility, Spring will continue to be years ahead of the slow Java EE cycle.

Similar Posts

Share this Post
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Slashdot
  • Technorati
  • Twitter
 

7 responses


  1. Why Spring 3 on JavaEE 6 server? For me that's obvious – about 98% of all applications that's going to be deployed on GF3 or soon-to-be-released JBoss6, or not-so-soon-to-be-released WS8 are *existing* applications, and 90% of them are applications which were started in the dark days of J2EE.

    For me Spring is a safe bet, because when company decides to switch to WebSphere 8 and then 9 from political-only reasons (some companies decided to stay with WS 6, because switching from 5 to 6 was painful and didn't changed anything) my applications won't stop working.

    Also I don't trust JavaEE parts provided by server – I prefer Hibernate (in whatever version I like), Hibernate-Validator in my WEB-INF/lib, because that's the version used in unit, integration tests and on Hudson CI server.

    About these 2% of new apps, for which some project managers are going to choose "vanila JavaEE 6" – good luck – see you later during JavaEE6-JavaEE7 transition where 99% of CDI extensions will be prefixed with "seam-".

    regards
    Grzegorz Grzybek


  2. Sounds mostly like cheap marketing. Change it a bit and Red Had could post it on their website and tell us that JEE 6 is better than Spring.

    I think that maybe you are fearing a bit the competition. Before JEE 6, Spring was clearly better in many areas but now with CDI (which is IMHO better then DI in Spring 3) and the other improvements, it will be harder to sell Spring to developers and customers. That does not mean that Spring is bad but it is not better anymore than JEE 6.

    So I think both the Spring and the JEE 6 people should talk more about programming than trying to convince others why their solution is better. Of course, with the huge amount of money involved, this won't happen.

    I think one should use either JEE_ 6 OR Spring (or JEE with specific Spring solutions like Spring Batch of tasks outside the server). No point in mixing this in any way. And GWT or Wicket can also be used with CDI (or it is currently in the making, check the jboss.org website).

    And Spring is not the only thing that is "evolving". There are projects like Seam 3 that provide many additions to JEE 6 (although Seam 3 is not yet final).
    By the way, over 40% of the people in the US don't "believe" in Evolution at all so neither Spring nor JEE can evolve :-)


  3. "currently in the making" and "not yet final" are common terms in JavaEE6 world 10 months after it's release…


  4. I agree that it takes quite some time until all the stuff is final. At the moment, we cannot use JEE 6 as we use JBoss 5 and JBoss 6 is not yet final. It really takes a long time.

    Also, I think that moving from Seam 2 to CDI/Seam 3 will take some effort but we really like all the new features in the standard and will probably go for it once JBoss AS 6 is here.
    That said we currently also test the JEE 6 versions of our software in Glassfish 3 and have absolutely no problems.

    We also use Spring Batch on the side and love it. This is very cool stuff!

    I think it will be a matter of taste in the future. Either Spring 3.x or JEE 6 Seam 3 (or standalone when sufficient).
    Using JEE 6 with some extra stuff from Spring like Spring Batch is currently our way to go and we like the results so far.

    A few things are annoying with JEE 6, for example that some annotations are there twice in different packages (e.g. @Managedbeans). This is confusing and @Managedbean shouldn't be used anyway (use @Named). They should have cleaned up this mess before releasing the standard.

    Another problem is, that some of the new JEE 6 books do not cover CDI. There is a huge lack of knowledge among developers about CDI which may be it's worst problem. I've talked to many people who like JEE 6 (Servelt 3, EJB 3.1, etc) but don't know much (or anything at all) about CDI.
    This is not a technical problem of CDI (I think Gavin and the others created something really great with CDI) but slow down adoption, at least until more people know about and understand CDI.

    In the end I think that if a programmer cannot create something great with Spring 3, JEE 6 won't be of much help either.

    I hope my first post was not too negative. I've used Spring very successfully and never had any problems with it. Keep up the great work.

    Claus


  5. I admit it, that was quite cheap marketing on my side – for GlassFish 3, that is, and for choosing Java EE 6 as a runtime platform even when having chosen Spring already. Sorry but I just can't help it: I will do that again in my talk at SpringOne here, coming up in less than an hour.

    Seriously, I am an advocate for the power of the combination. I just don't buy the propaganda argument that it is either Spring 3 or EE 6. The fact that some EE 6 books don't even cover CDI is a good indication that the world doesn't fundamentally change with EE 6: i.e. that EE 6 is just as good a runtime platform for Spring-based applications as EE 5 was. The perceived overlap isn't a problem in practice, just like before.

    Also, I'm personally spending a lot of energy on making the combination work well, and have been doing so for way more than a year already. Also, I am usually the one talking to the Spring audience about EE 6 – in a constructive and pragmatic fashion. This includes pointing out the strengths of the modern middleware package that is EE 6, but also pointing out the implications in terms of limited deployment platforms.

    I am essentially picking up people where they are: e.g. using Spring on WebSphere 6.1 or possibly 7, and wondering what EE 6 will mean to them – given that their data center won't see WebSphere 8 before 2013 or so. Explaining that they can use key parts of EE 6, such as JPA 2.0, through a feature pack on WebSphere 7, in combination with Spring 3's JPA 2.0 support – that's of more immediate relevance to those guys.

    Juergen


  6. EE7 should (or rather MUST, else it may never see the light ;-) be modular!
    Whether based on OSGi, Jigsaw or a bit of both, that's to be decided (and at least indirectly via OSGi or Eclipse SpringSource should also be present ;-)

    So there will be less a question of "JavaEE vs. Spring" or "Seam vs. Spring", than "What is right for me?".

    Many people at a recent event that still has "Java" in its name asked why and where you'd need Spring if you got Glassfish. IOC is a good example where alternatives have driven the standardization process while SpringSource and others were just watching. Tapestry is still even further behind btw, so don't worry.

    A real integration of previously separate and often developped without caring about other parts of the ecosystem is what EE7 shall also bring. Then you can "Mix & Match" to some extent although many vendors currently try to lock developers into their own portfolio.

    Werner
    (JCP SE/EE EC Member)


  7. Java Server Pages and Servlets are really the same thing. These are useful for distributed applications in that they can be used to create web-applications. A servlet container is needed for deployment of JSP/Servlets. The servlet container would compile the JSP into a servlet.

One trackback

Leave a Reply