Separation of Concern: JDBC drivers

[kjkoster]

Dear All,

There seems to be some disagreement as to where to place key JAR files in JEE application servers. In particular, where to place the JDBC driver JAR? In the container or in the web application?

Let's consider the roles around a container that is running in production. In a very simplified model those roles are system administrator and developer. And they can be responsible for three things, again in a simplified model: the web application, the JEE server, or the OS and hardware below that.

Most shops agree that system administrators are responsible for the hardware and the OS. Let's go with that, for the sake of argument. When it comes to the web application, the responsibility rests with the developer. That is the person who creates the application and packages it for deployment. All clear so far.

When it comes to the JEE server, responsibilities become a lot more vague1. In some shops the application developers package a JEE server with their application, offering the combination as the deployment unit. In other shops, the JEE server is managed by the system administrators, and the developers deliver WAR files as the deployment unit. The image jdbc_jar_responsibility.001.jpg illustrates this.

In a shop where the developers are responsible for both the JEE server and the web application, placement of the JDBC driver is entirely a matter of taste. I would say: he who does the work decides.

Most shops have a model where the JEE server is a system administrator responsibility, and the developers stick to making web applications. For such situations, placement of the JDBC driver JAR reflects the responsibility of configuring the database access. In other words, the team that configures the database URL, user name and password gets the JAR file in its domain.

Thus, if the developers have the passwords to the production databases, the configure them in their web application and they keep the JDBC driver JAR in WEB-INF/lib.

If on the other hand, the administrators are responsible for providing the database connection settings, that is best done through a data source that the container provides to the web application. This frees the application from most of the database dependency. The image jdbc_jar_responsibility.002.jpg illustrates this.

Then again, sometimes the web application needs a very specific database driver to work (Oracle objects, I'm looking at you). In that case, the JDBC driver goes into the web application again. It's part of the code in that way. Setting the JDBC connection properties without revealing them to the developers is left as an exercise to the reader.

Kees Jan

1. Of course, there are shops where the developers and administrators are still haggling over who is responsible for what. In that case, the location of their JDBC drivers is the least of their worries. ;-)

[Kees de Kooter]

For development purposes I usually create my own datasource. The jdbc driver can then be either in a shared director of the app server or in the app itself.

For testing and production deployment I package the application without this datasource and have it rely on a container provided datasource (and as a consequence the jdbc driver needs to be available at the app server level).

The main advantages to using a container provided datasource:

security - the developer does not need to know the database production credentials
loose coupling - database urls can be changed without a need to repackage and redeploy the application
externalization of application configuration.


my 2c
Kees de Kooter

[sadovnikov]

In smaller shops, where role of system administrator is... not clearly defined, developers very commonly put lots of unnecessary jars to WEB-INF/lib directory. One (or more) of these jars will be JDBC driver.

In my opinion WEB-INF/lib should include only jars required at compile time. All other jars are only messing up with class loaders. Run-time dependencies (on libraries, data sources, jms factories, etc) should be either in the deployment descriptor (what is possible to put there) or simply listed for system administrators: "Make sure these libs are in the class path"

In IBM I worked with WSAD and WebSphere AS. They use their own specific files, which are not in J2EE specs, but make the work of system administrator at deployment time much easier: he gets his application resources pre-configured. But nothing could help against jars of different versions in WEB-INF/lib directories of applications and class path of AS.

[kjkoster]

Interesting. I tend to try and make a web application as self-contained as possible. Having the sysadmins install things like log4j and XML parsers in the containers invariably leads to version issues, IMHO. Funny that you would propose the reverse solution for the same arguments that I use.

[andrejk]

I agree with the self-contained statement, but i've run into some problems regarding the jdbc drivers that lead me to think that it's not possible, at least not on oracle's application server.

I think if you define a datasource in oracle's oc4j (enterprise manager) the jdbc classes needed for the datasource are required on the classpath of the jee container (oc4j). If you also add the jdbc classes to the classpath of your webapplication, they are considered different classes, because they are loaded by a different classloader, even if they're exactly the same java classes.

If some of your jdbc classes are loaded from a jar in the classpath of the container, and some of your jdbc classes are loaded from a copy of the same jar on your webapp classpath you'll run into class cast exceptions.

It's not a good idea to have the same jdbc jar in different locations, but you need it in the container, otherwise you cannot provide the datasource configuration in the management console.

[kjkoster]

Dear andrejk,

I agree. Oracle forces the separation so that data sources are always in the system administrator domain. The do the same thing with Toplink and some other stuff.

Kees Jan