{"id":67,"date":"2014-07-25T13:00:27","date_gmt":"2014-07-25T13:00:27","guid":{"rendered":"http:\/\/www.solewing.org\/blog\/?p=67"},"modified":"2014-07-25T13:21:13","modified_gmt":"2014-07-25T13:21:13","slug":"wildfly-datasource-deployment","status":"publish","type":"post","link":"http:\/\/www.solewing.org\/blog\/2014\/07\/wildfly-datasource-deployment\/","title":{"rendered":"Wildfly Datasource Deployment"},"content":{"rendered":"

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

JDBC Driver Deployments<\/h2>\n

The ability to treat a JDBC driver as a deployment depends on the Java\u00a0service loader<\/a>\u00a0mechanism that was introduced with JDK 6 and incorporated in JDBC 4. \u00a0Virtually 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\u00a0deployments<\/em>\u00a0directory. \u00a0Once the JDBC driver has been deployed, one or more datasources can be configured that make use of it.<\/p>\n

DataSource Deployments<\/h2>\n

The ability to deploy datasource configurations is enabled\u00a0by IronJacamar<\/a>\u00a0which Wildfly uses for its Java Connector Architecture (JCA) support. \u00a0 An IronJacamar datasource configuration is specified in an XML file that defines\u00a0the JNDI name for the datasource along with all of the configuration needed to access and manage the underlying database resource.<\/p>\n

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.<\/p>\n

[xml]
\n
\n
\n
\n jdbc:mysql:\/\/localhost:3306\/my_database<\/connection-url>
\n com.mysql.jdbc.Driver<\/driver-class>
\n mysql-connector-java-5.1.29.jar<\/driver>
\n
\n my_username<\/user-name>\n my_password<\/password>\n <\/security>
\n
\n
\n
\n
\n <\/validation>
\n <\/datasource>
\n<\/datasources>
\n[\/xml]<\/p>\n

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

By copying my_datasource-ds.xml<\/code> 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.<\/p>\n

XA DataSource Deployments<\/h2>\n

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.<\/p>\n

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.<\/p>\n

[xml]
\n
\n
\n <\/p>\n

localhost<\/xa-datasource\n-property>
\n 5458<\/xa-datasource-property>
\n my_database<\/xa-datasource-property>
\n org.postgresql.xa.PGXADataSource<\/xa-datasource-class><\/p>\n

postgresql-9.1-902.jdbc4.jar<\/driver>
\n
\n my_username<\/user-name>\n my_password<\/password>\n <\/security>
\n
\n
\n true<\/validate-on-match>
\n false<\/background-validation>
\n
\n
\n <\/validation>
\n <\/xa-datasource>
\n<\/datasources>
\n[\/xml]<\/p>\n

Note that the property names specified by <xa-datasource-property><\/code> are driver specific \u2014 a driver from another database vendor would use different property names.<\/p>\n

References<\/h2>\n