views:

368

answers:

2

I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (theoretically) means we can switch JPA providers via configuration (e.g. without changing source code) -- (right???).

When running within a servlet container (e.g. Tomcat, Jetty) the application is configured to run with Hibernate. We choose Hibernate over TopLink and Eclipselink for its maturity and performance. So far this works.

However, when running within a JEE application server, should we default to the JPA provider therein, or stick with Hibernate?

I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.

I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?

+1  A: 

I don't see what you will be missing, unless you're using implementation specific API in your JPA code. I.e. do not import org.hibernate anywhere in your JPA code, but just write it against the JPA API.

BalusC
So your saying stick with Hibernate when running in Websphere, Glassfish, etc.?
HDave
I'd let the client/serveradmin provide the JPA implementation of their own choice and not push a specific implementation through their throat.
BalusC
+1  A: 

I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (...) means we can switch JPA providers via configuration (...)

Yes.

(...) However, when running within a JEE application server, should we default to the JPA provider therein, or stick with Hibernate?

Well, if you deploy on a Java EE 6 server, this doesn't really matter. It's not clear who is going to run the application and you can maybe make recommendations but the runtime is actually "not your business" :) Also note that you may not benefit from support if you don't use the default provider (if this matters).

I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.

First of all, keep in mind that JPA 2.0 is part of Java EE 6 and that GlassFish v3 is the only one Java EE 6 container at this time. WebLogic and WebSphere are Java EE 5 server, they may not support JPA 2.0.

Now, regarding the default providers:

  • GlassFish v3 uses EclipseLink 2.0 as default provider but can be configured to use Hibernate 3.5 (through an add-on).

  • In Weblogic 10.3.2, the default JPA provider is OpenJPA/Kodo and EclipseLink 1.2 is available as a WLS module. In WLS 10.3.3 (not released yet), EclipseLink 2.0 will be available as a WLS module, the default being still OpenJPA/Kodo. But, the container JPA API will still be JPA 1.0! It seems possible to package a JPA 2.0 provider inside your application. See this thread and this page. But this is not officially supported and doing this same thing with Hibernate 3.5 might be another story.

  • In WebSphere 6 and 7, the default provider is OpenJPA. This link will give you some details about the way to change the default provider (and the consequences). But I can't tell you more.

I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?

As I mentioned, this may not be supported by the vendor. Additionally, if you want to maximize portability and plan to deploy your application in a near future, going for JPA 2.0 is maybe not a wise choice (or too optimistic if you prefer).

Pascal Thivent
Thanks for the detailed answer. For what its worth it looks like JPA2 for Websphere 7 is now available:http://webspherecommunity.blogspot.com/2010/06/osgi-applications-and-jpa2-feature-pack.htmlHowever, when this will end up in the hands of production customers is another thing.
HDave