Why JPAs persistence.xml sucks

Have you ever tried to develop an Java 6 EE application on different application servers? In production we are forced to use WebSphere AS. I like the configuration interface but that’s all. WAS is not usable during development because the deployment cycles are way too long. Because of this we use JBoss AS 7.1.1 in our development environment. Our application uses Java 6 EE features in service (EJB, CDI) and presentation (JSF, CDI) layer but still uses a DAO layer which is managed by Spring. The DAOs get injected by SpringBeanAutowiringInterceptor. For consistency I had planned to port the Spring DAO layer to Java 6 EE.

First of all our Spring configuration uses the correct database connection settings (Hibernate transaction manager, JNDI name) by a simple environment switch which can be set in the application server. By default, the production configuration for WebSphere is used. If you populate an environment key jndi-jboss, the JBoss settings are loaded on startup. This approach introduced a new architectural complexity but fits exactly our needs. Using JPAs persistence.xml and reaching the same goal should be doable, right?

Well… no. First of all, the JPA configuration is simply not designed to handle different environments. This would not be a problem if an application server specific file like jboss-persistence.xml or ibm-persistence.xml would be used by JBoss repsectively WebSphere. On application startup the application server would load the designated persistence.xml and everything is fine.
My approach was to write a simple parser for properties inside persistence.xml which can be evaluated against system properties, like

 		<!-- Remove the hibernate.transaction.manager_lookup_class setting -->
 		<property name="?(applicationserver.runtime=jboss)hibernate.transaction.manager_lookup_class" value="" />
 		<!-- Overwrite the setting -->
 		<property name="?(applicationserver.runtime=jboss)jta.UserTransaction" value="java:comp/JBossUserTransaction" />

Writing and testing the parser was an easy task so I tried to integrate it in the startup process. JPA has no InitializePersistenceContext handler or something else which is executed on startup. The only possibilty was to extend the Hibernate persistence provider and define my own provider inside the persistence.xml. The idea seemed good but did not work. Persistence providers must be deployed in the application server. JBoss only threw an Persistence Provider not found exception. While I was searching for an easier solution (which probably does not exist – you must deploy the provider inside the application server, at least in JBoss) I came upon a blog post which said, that it is not possible to reference a data source in persistence.xml through a res-ref-name resource. Huh? I do need this, otherwise I am not able to specify the JNDI entry independently from my application server. My jboss-web.xml contains a reference to the JBoss data source while the original web.xml holds the reference to the WebSphere data source.
I reached the point where I decided not to go with a pure Java EE 6 implementation and keep the Spring backend. The only solution is adjusting our Maven build process and creating different EAR artifacts for JBoss and WebSphere, which does not solve the problem to easily deploy the application through Eclipse into one of the application servers.

Update (2014-01-29): I opened a feature request in JBoss’ JIRA (https://issues.jboss.org/browse/WFLY-2816) and put a message on the mailing list. A solution for this problem is to add a check for a jboss-persistence.xml in favour of the original persistence.xml.