views:

90

answers:

3

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.

+5  A: 

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.

Pascal Thivent
@Pascal Thivent: (relevant to the paragraph about the connection pool) could you add some links or explain a little? I would agree with your point (and I did it as you describe several times because it's the most intuitive way), but I was told that it's a bad practice (because same libraries in app-server and in deployed app can cause conflicts) and all libraries should be packed in application's war-file. This is more actual for cases, when more then 1 app is deployed on the same server (tomcat in my case).
Roman
To expand on the last sentence: a JNDI datasource is container managed and *implicitly requires* the driver to be present in container's library. The container won't scan the WAR libraries for drivers. This indeed ends the discussion :)
BalusC
@Roman Sure, see the [Apache Tomcat 6.0 Class Loader HOW-TO](http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html). If you want to use Tomcat's **built-in** connection pool, the driver must be available in $CATALINA_HOME/lib or Tomcat won't be able to load it.
Pascal Thivent
This is a better resource: [JNDI HOW-TO - JDBC Data Sources](http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC_Data_Sources). Note that it explicitly recommends to place the driver in `tomcat/lib`.
BalusC
@BalusC Yes, this is a good one. Thanks.
Pascal Thivent
@Pascal, BalusC: thanx, I've never used built-in tomcats connection pool but would know if ever need to do that.
Roman
+5  A: 

In most of the applications, JDBC drivers aren't shipped as part of the application.

If you do ship JDBC drivers, that means that you have to give drivers for all the database you want to support. It add a lot of unnecessary libraries.

Just don't add any driver, and tell the user to put the relevant JAR file in the server libraries if needed.

Vivien Barousse
+1  A: 

Other then the technical merits of including the driver in the war file, You should also check up the licensing for the driver and make sure that it is distributable by a third party.

Pratik Bhatt