Should JDBC drivers be included in a WAR?

We have a commercial software product under development. It supports Oracle, MySQL, and SQL*Server backends (we also use H2 for testing). We do our integration testing against those different database using JDBC drivers of a specific version. Maven handles all this beautifully.

When packaging the application as a WAR, is it ok if we include the JDBC drivers? What is the standard practice?

Since we don’t know which database could be used ahead of time, we’d have to include them all. The targeted servlet containers are Tomcat and Jetty, but some customers will also want to run within WebSphere and JBoss.

So the servlet contains and application servers come with their own JDBC drivers? Will ours conflict? Another concern is that we have developed and tested with one version of the driver and if a customer uses another version, we may have problems.

Currently we use Spring data source beans, but are in the process of moving to JNDI lookup for the datasource.

Answer

So the servlet contains and application servers come with their own JDBC drivers?

Some do (e.g. WebLogic).

Will ours conflict?

They shouldn’t. Not sure yours will be picked when creating an standalone connection pool at the application level though (it all depends on the classloader delegation mode).

Another concern is that we have developed and tested with one version of the driver and if a customer uses another version, we may have problems.

Have a list of supported versions.

Currently we use Spring data source beans, but are in the process of moving to JNDI lookup for the datasource.

If by this you mean using the connection pool provided by an application server, drivers must be installed at the container level, not at the application level. And this somehow ends the discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *