Tutorial : How to Swap Oracle JDBC Drivers

Introduction
This how-to serves purely as a demonstration of the mechanics behind changing the version of the Oracle JDBC driver used by an application running on OC4J. It does not serve as a statement of certification for any specific OC4J/JDBC driver combination. All certification information should be obtained from Oracle Support or via the Oracle Metalink web site -- http://metalink.oracle.com.

This how-to demonstrates how the shared-library mechanism – introduced in OC4J 10g (10.1.3) – can be used to define which Oracle JDBC driver is loaded for a specific application.

Note: See the OC4J Configuration and Administration Guide for a detailed discussion on the shared libraries functionality available in OC4J.

This how-to contains an application which makes a database connection and prints out the version of the Oracle JDBC driver it has used. To demonstrate the shared-library capabilities, a different Oracle JDBC driver version is installed and published as a shared-library and the application is re-configured use the new shared-library.

Like many other application servers, OC4J is configured to load a pre-defined set of libraries. For instance, all of the J2EE libraries supported and implemented by a specific release are loaded when OC4J starts. Additionally, the Oracle JDBC drivers that ship with the distribution are also loaded and made available to applications by default. The standard approach is that the version of Oracle JDBC driver which is included is from the corresponding version of the database on which the OC4J version has been built and tested. Typically this is a handy situation for users of OC4J, eliminating the need to track down a set of JDBC drivers for use with an application.

However, there are situations where an application will requires a specific version of JDBC driver other that what has been provided with OC4J. Up until the 10.1.3 release, this has proven to be a non trivial problem for users of OC4J.

The main problem has been that the JDBC libraries have been hard coded into the classpath of the container using the referential JAR file Class-Path mechanism. Altering this has required the use of the JRE extension library mechanism, or altering the boot classpath of the JVM when it is launched to load the alternative JDBC driver version instead. While this works, it has been an unsupported operation, since the effect of this change is not limited to a specific application – the effect is felt across the entire container and may lead to unpredictable results at runtime. A similar situation has also arisen from time to time with the requirement to utilize a different XML parser implementation (such as Xerces) than the one baked into OC4J.

But a solution is now at hand with the introduction of the shared-library mechanism with OC4J 10g (10.1.3). Using the shared-library mechanism, classes can now exist within a parallel classloading space, enabling a clean separation to be made between the libraries used by OC4J itself and the libraries used by applications deployed to OC4J.

With this shared library implementation, it is possible to specifically override and replace any of the default class libraries which are loaded and made available by default. This can be done on an individual application-by-application basis or rolled up to a set of defaults inherited by each application

[Read More..]

Courtesy:- Oracle.com