Spring+JPA to be the next popular stack?

Posted by Floyd Marinescu on Jun 07, 2006

Sections

Topics

Spring+Hibernate is often called the most commonly used stack behind java web applications these days.   While the today-JCP-approved Web Beans JSR would standardize a web stack combining JSF+EJB+JPA and many elements from JBoss Seam (excluding Spring),  and EJB 3 now providing a simplified session bean framework with basic interception and dependency injection,  Spring 2.0 now provides the complete EJB container contract for JPA, allowing JPA to be used under a Spring managed services layer (with all the AOP and DI richness of Spring) in any environment.   Debates are already beginning about whether the next defacto stack will be EJB, Spring+Hibernate, or Spring + JPA.

Using JPA in standalone has been demonstrated on Tomcat and on Geronimo, but this method suffers some limitations, for example the a persistence context cannot be shared across Entity Managers in the same transaction automatically.  By implementing the ejb container contract, Spring allows the injection of the persistence across components in the same transaction, as well as the ability to have components join transactions and also support for extended persistence context.   Spring 2 thus allows the use of JPA with all the features supported within a container.

Mark Fisher recently demonstrated JPA with Spring in a standalone environment using the Toplink Essentials JPA reference implementation from Glassfish.  Mark took a simple JPA domain model and showed now it could run in Spring:

I am going to extend Spring’s JpaDaoSupport class. This provides a convenience method for retrieving the JpaTemplate. If you have used Spring with JDBC or other ORM technologies, then you will probably be quite familiar with this approach. It should be noted that use of the JpaDaoSupport is optional. It is possible to construct a JpaTemplate directly by simply providing the EntityManagerFactory to its constructor. In fact, the JpaTemplate itself is optional. If you do not wish to have the automatic translation of JPA exceptions into Spring’s runtime exception hierarchy, then you can avoid JpaTemplate altogether. In that case, you may still be interested in Spring’s EntityManagerFactoryUtils class which provides a convenient static method for obtaining the shared (and thus transactional) EntityManager.

Spring 2.0 documentation has also been updated with a section showing how JPA is supported in the same way as Hibernate or TopLink.   At Java One, Rod Johnson mentioned to InfoQ that Spring is putting a lot of effort into ensuring portability into JPA integration, the aim being to easily allow the swapping of JPA providers such as Hibernate, TopLink, OpenJPA, etc.

Recently, Spring's project Pitchfork (which provides parts of the full EJB api's to WebLogic) was used to demonstrate deploying full EJB on Tomcat, although full EJB on Tomcat with Spring is not intended for production use, Rod Johnson mentioned that "the intent is not to write an EJB container."    JBoss is also offering an embeddable EJB container that can run EJB 3 on Tomcat, with some limitations.  

A huge debate errupted between Gavin King and various Spring folks last week about JBoss and EJB 3 vs. Spring "quasi-ejb container" (as Gavin put it).  The Spring folks maintain that JPA is the main value of the new EJB spec and session beans are a poor subset of Spring in terms of dependency injection and AOP capabilities, and are pushing Spring+JPA. Gavin King responded saying that they are attempting to promote further Spring lock-in by pushing Spring instead of building "addons for EJB3 via the extension points provided by the spec."

2006 and 2007 will definitely see a lot of competition and innovation for the next defacto standard for transactional, persistent java web app development. Their appear to be three camps,  Sun/JCP, JBoss, and Spring.  Will the community rally around EJB or shrug it off and stick to Spring+JPA or Spring+Hibernate?  When Web Beans finalizes, things will get even more interesting, and InfoQ will be here, to track the change and innovation that will be occuring at each step.

1. Back to top

   Competition is good

   by Rod Johnson

   2006 and 2007 will definitely see a lot of competition and innovation for the next defacto standard for transactional, persistent java web app development.

   
   Indeed, but we should remember also that not all applications are web applications. For example, of the several hundred jobs currently requiring Spring in London (from www.jobserve.co.uk yesterday) there are pages and pages of banking and other financial sector jobs, many of which are not web applications.
   
   Innovation and competition is good. I'm looking forward to the developments of the next couple of years and I think the user community will be the big winner.
   
   Remember the bad old days when people tried to apply the original Sun PetStore style J2EE architecture? When there wasn't vigorous innovation and competition in the space (because the EJB spec had all the answers)? We've come a long way and have further to go.

   Reply

2. Back to top

   Camps

   by Corby Page

   There appear to be three camps, Sun/JCP, JBoss, and Spring.

   
   
   It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.

   Reply

3. Back to top

   extended persistence context and implementation subtleties

   by Gerald Loeffler

   on a practical aspect of this detbate: one feature of EJB3 that i find particularly interesting, innovative and potent is the combination of the extended persistence context and its injection into stateful EJB3 session beans: i, for my part, would only trust a fully Java EE 5 certified container (once this exists) to correctly implement all subtleties in this area of EJB3. The idea to have that same EJB container execute my unit tests outside the application server seems very convincing, IMHO.
   
   cheers,
   gerald
   
   www.gerald-loeffler.net

   Reply

4. Back to top

   Re: Camps

   by Gavin King

   There appear to be three camps, Sun/JCP, JBoss, and Spring.

   
   
   It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.

   
   
   Note that we are working very closely with Sun and others to create a JCP-standard solution in this space. JBoss is deeply committed to the idea of innovating in open source, and bringing those innovations that work in practice back into the standards process.
   
   We agree with Tim Berners-Lee that a technology well never be a universal technology if someone owns it. Monopolies stunt technology and stunt the growth of marketplaces.

   Reply

5. Back to top

   Re: Camps

   by Floyd Marinescu

   There appear to be three camps, Sun/JCP, JBoss, and Spring.

   It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.

   Note that we are working very closely with Sun and others to create a JCP-standard solution in this space. JBoss is deeply committed to the idea of innovating in open source, and bringing those innovations that work in practice back into the standards process.
   
   We agree with Tim Berners-Lee that a technology well never be a universal technology if someone owns it. Monopolies stunt technology and stunt the growth of marketplaces.

   
   Indeed I did not mean to imply with the camps point that JBoss is not working with Sun, I agree that JBoss is committed to standards, as evidenced by the large contributions to the EJB spec.
   
   The intention behind that point was to identify the groups that are actively developing and promoting their own approaches end to end stacks for web development, where these approaches have a real chance of becoming the next practical standard (as Spring Hibernate has).

   Reply

6. Back to top

   JPA needs more

   by Jason Carreira

   Spring JPA or EJB3 JPA will be problematic as long as the JPA standard has critical missing features, namely a Criteria API and Filters, which I've become addicted to in Hibernate.
   
   Rod has talked about implementing this stuff in Spring's JPA support, which would be excellent if it can be made portable across implementations (at which point it should be rolled into JPA 2), but until then people like me will have a hard time justifying a switch from Hibernate or JDO, both of which are richer in these other areas, to a JPA provider.

   Reply

7. Back to top

   Re: JPA needs more

   by Gavin King

   JPA will be problematic as long as the JPA standard has critical missing features, namely a Criteria API and Filters, which I've become addicted to in Hibernate. .... people like me will have a hard time justifying a switch from Hibernate or JDO, both of which are richer in these other areas, to a JPA provider.

   
   
   The reason that JPA does not have a Criteria query API, or anything like Hibernate's unique Filter functionality is that these things were judged to be pretty exotic features. No, JDO absolutely does not have either of these features. No, AFAIK, there is no other product on the marketplace which has a Hibernate-like Filter construct for dealing with temporal/regional data.

   Reply

8. Back to top

   Re: JPA needs more

   by Rick Hightower

   RE: The reason that JPA does not have a Criteria query API, or anything like Hibernate's unique Filter functionality is that these things were judged to be pretty exotic features.
   
   I agree with Jason Carreira. I don't find the Criteria API exoctic at all. I tend to use it a lot for filterable, paginateable tables. It helps me deliver a rich user experience.
   
   I look forward to Spring (or some framework) providing a common Criteria API.

   Reply

9. Back to top

   Re: Competition is good

   by Solomon Duskis

   
   Innovation and competition is good. I'm looking forward to the developments of the next couple of years and I think the user community will be the big winner.
   

   
   
   The user community will definitely be a winner. The vendors that produce the most innovative, or at least the most used products and services will also be big winners :).
   
   

   
   Remember the bad old days when people tried to apply the original Sun PetStore style J2EE architecture? When there wasn't vigorous innovation and competition in the space (because the EJB spec had all the answers)? We've come a long way and have further to go.

   
   
   I thought that there were lots of architecture styles in the "old days." IBM, Sun, Microsoft and other shops had their own solutions. J2EE consolidated some of those architectures. As a result, the user community was left with a difficult period of trying to understand what to do with the new architecture. Some inevitable push-back happened and then we went back to more consolidation...
   
   "Unless simple things are simple, complex things are impossible" (Alan Kay). Innovation makes complex things are simpler, and in turn that makes some "impossible" things merely "complex."
   
   I think we'll always have "further to go." There's probably room to go further in lots of different directions.

   Reply

10. Back to top

    Re: JPA needs more

    by Rick Hightower

    I implemented a Java DSL (API) for Criteria queries for JPA.
    
    See.... www.jroller.com/page/RickHigh?entry=i_implement...
    
    For more details.
    
    You can even download it here...
    code.google.com/p/krank/
    
    Enjoy... Let me know what you think

    Reply

• Older >