Datasource bindings configuration on JBoss AS 7 and Cloudbees

I'm writing this article after I tried to configure a web application in a way that the same war package could be deployed in both JBoss and cloudbees with no configuration changes.
I thought it would be possible using the resource-ref element in the web.xml which should decouple the JNDI binding name from the application and the container, but it seems to be not totally true, at least for JBoss and Cloudbees (maybe one of the two is doing it correctly, but I don't know who!)

The final result shoul be a web application which uses a JPA persistence unit defined in the persistence.xml, on top of a MySQL DB.
The web application uses the web.xml to declare a "datasource-type" resource, which will be referenced by the persistence.xml as its jta-datasource.

How to binding the "datasource-type" resource declared in the web.xml to an actual datasource provided by the application container depends on the container.
For the JBoss AS 7 this is done through the jboss-web.xml configuration file, where the web.xml "datasource-type" resource is mapped to an existing JNDI name. This JNDI name should refer to an existing datasource configured in the JBoss standalone.xml file.
With cloudbees, the datasource is simply configured in the cloudbees-web.xml.

So, here is the list of the involved components:

  • A MySQL database named localTaskrDB running locally (for JBoss) and a MySQL database running on cloudbees, named remoteTaskrDB
  • A "datasource-type" resource declared in the web.xml (<res-ref-name>taskrDS</res-ref-name>)
  • The JPA persistence.xml configuration file where we declare a persistence unit which will use the datasource reference declared in the web.xml (<jta-data-source>taskrDS(*)</jta-data-source>)
  • The "real" datasource, which will be configured differently for each container:
    • JBoss AS 7: the "real" datasource is configured in the standalone.xml, while the jboss-web.xml configuration file acts as a "bridge" from the resource declared in the web.xml (taskrDS) and the real datasource declared in the standalone.xml
    • Cloudbees: the "real" datasource is configured simply in the clodubees-web.xml file

(*) The problem is here. I though that the jta-data-source value of the persistence unit should have be the same of the res-ref-name declared in the web.xml. But this works only in cloudbees! In JBoss, the resource declared in the web.xml as a res-ref-name, is registered in the java:comp/env/ context!!


Here we declare a "datasource type" resource with the "logical" name taskrDS:


Here we declare a persistence unit which use the datasource defined in the web.xml, putting it in the jta-data-source element.
The thing is that here I should have expected to simply put the taskrDS value, as declared in the web.xml. But it's not totally true since it works only for cloudbees. For JBoss we have to add the java:comp/env/ prefix:

<persistence-unit name="primary">
	<!-- for JBoss AS 7 -->
	<!-- for cloudbees  -->

This file is specific for JBoss and it is used to bind the datasource defined in the web.xml to a real JNDI name, specific for the container. The resource-ref element for the jboss-web.xml is similar to the one in the web.xml, but here we add the jndi-name element:


jboss default.xml configuration file
In this file we configure the datasource used to connect to our MySQL DBMS, and the jndi-name declared here is referenced in the jboss-web.xml:

<datasource jta="true" jndi-name="java:jboss/datasources/localTaskrDS" pool-name="LocalTaskrDS" 
enabled="true" use-java-context="true">

In this file we configure a datasource in cloudbees, used to connect to the remote DB:

<resource name="taskrDS" auth="Container" type="javax.sql.DataSource">
	<param name="username" value="username" />
	<param name="password" value="pwd" />
	<param name="url" value="jdbc:mysql://" />

The summary is that I failed to create a war which is deployable on both cloudbees and JBoss AS7 with no modification. However it's not too bad since we only need to update the jta-data-source value of the persistence.xml, but this conclusion makes me wonder of the utility of declaring a datasource type resource in the web.xml, which adds another layer, but still, container dependent!!