At this point, you might wonder which is the best practice for deploying the JDBC driver. Actually, installing the JDBC driver as a deployment unit is an handy shortcut, however, it has a couple of limitations that might limit is usage within development bounds. At first, it requires a JDBC 4-compliant driver.
Deploying a non JDBC 4-compliant driver is, however, possible and it just requires a simple patching procedure. Create a META-INF/services structure containing the file
java.sql.Driver. The content of the file will be the driver name, for example, supposing you had to patch a MySQL driver, the content will be:
Once you have created your structure, you can update your JDBC driver with any zipping utility or the .jar command: jar -uf your-jdbc-driver.jar META-INF/services/java.sql.Drive.
Most current JDBC drivers are JDBC 4-compliant, although curiously, not everyone is recognized as such by the application server. The following table describes some of the most used drivers and their JDBC compliance:
As you can see, the most notable exception to the list of drivers is the older Oracle ojdbc4.jar, which is not JDBC 4-compliant and does not contain the driver info in META-INF/services/java.sql.Driver.
The second issue with driver deployment is related to the specific case of xa-datasources. As a matter of fact, by installing the driver as deployment means that the application server by itself cannot deduct the information about the xa-datasource class used in the driver. Since this information is not contained inside the META-INF/services, you are forced to specify information about the xa-datasource class for each xa-datasource you are going to create.
If you recall the earlier example, where we installed a driver as a module, the xa-datasource class information can be shared for all installed datasources.
So, in definitive, if you are not too limited by these issues, installing the driver as deployment is a handy shortcut, which can be adopted in your development environment or as well, if you feel more adventurous, also in production.
For the happiness of programmers, we will account for one more option to configure a datasource which requires zero file configuration. In fact, one cool feature of Java EE 6 is support for configuring a datasource programmatically, which can be done through the @DataSourceDefinition annotation:
In this example, we have defined a DataSource for an Oracle database into a Singleton EJB 3.1. It’s important to note that when configuring a datasource programmatically, you will actually bypass JCA, which proxies requests between the client and the connection pool.
The advantage of this approach is that you might obviously move your application from one application server to another without the need of re-configuring its datasources. On the other hand, by using JBoss’ own datasource configuration, you will be able to leverage a larger set of options and tweaks, which are required for many kinds of application.
Free Demo for Corporate & Online Trainings.