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.
Community comments
Competition is good
by Rod Johnson,
Re: Competition is good
by Solomon Duskis,
Camps
by Corby Page,
Re: Camps
by Gavin King,
Re: Camps
by Floyd Marinescu,
extended persistence context and implementation subtleties
by Gerald Loeffler,
JPA needs more
by Jason Carreira,
Re: JPA needs more
by Gavin King,
Re: JPA needs more
by Rick Hightower,
Re: JPA needs more
by Rick Hightower,
Competition is good
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Camps
by Corby Page,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
extended persistence context and implementation subtleties
by Gerald Loeffler,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Camps
by Gavin King,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Camps
by Floyd Marinescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
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).
JPA needs more
by Jason Carreira,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: JPA needs more
by Gavin King,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: JPA needs more
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Competition is good
by Solomon Duskis,
Your message is awaiting moderation. Thank you for participating in the discussion.
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 :).
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.
Re: JPA needs more
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
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