Tag Archives: wildfly

Wildfly Datasource Deployment

One of the things I really like about Wildfly and its immediate predecessors is the ability to deploy JDBC drivers and datasource configurations without needing to edit the configuration or restart the container.

JDBC Driver Deployments

The ability to treat a JDBC driver as a deployment depends on the Java service loader mechanism that was introduced with JDK 6 and incorporated in JDBC 4.  Virtually every database vendor has a JDBC4-compliant driver that can be auto-deployed in Wildfly by simply dropping the JAR file for the driver into the container’s deployments directory.  Once the JDBC driver has been deployed, one or more datasources can be configured that make use of it.

DataSource Deployments

The ability to deploy datasource configurations is enabled by IronJacamar which Wildfly uses for its Java Connector Architecture (JCA) support.   An IronJacamar datasource configuration is specified in an XML file that defines the JNDI name for the datasource along with all of the configuration needed to access and manage the underlying database resource.

Here’s an example (non-XA) datasource configuration for a MySQL datasource. As you can see, most of the element and attribute values in the file are fairly intuitive.



my_username my_password


You can deploy a datasource descriptor such as the previous example, by placing it a file with name that is suffixed with -ds.xml and dropping it into the deployments directory. The example datasource shown above might be named my_datasource-ds.xml.

By copying my_datasource-ds.xml into the deployments directory, IronJacamar will use the database driver specified in the descriptor to create a datasource object and bind it into the container’s JDNI registry with the given JNDI name. Once the datasource is deployed, your applications can access it just as they would any other JNDI resource.

XA DataSource Deployments

IronJacamar also supports XA datasources, which are important if you need to make use of transactions that involve more than one database and/or a database and a JMS message broker.

The configuration descriptor for an XA datasource is quite similar to the basic datasource, as you can see in the following example for an XA datasource using a PostgreSQL driver.




my_username my_password



Note that the property names specified by <xa-datasource-property> are driver specific — a driver from another database vendor would use different property names.