This technote describes a fix for a condition under which you receive exceptions trying to wrap JDBC drivers which have been loaded by a classloader other than that which loaded the FusionReactor system filter. This occurs primarily on manual installs, or J2EE platforms not supported by the installer (e.g. Websphere), or if you are using third-party JDBC Driver jars.
Customers using FusionReactor in environments where the FusionReactor JDBC Driver Wrapper (and subsequent wrapped driver) is loaded by a different classloader than that used to load the FusionReactor system filter may observe one or more of the following issues:
- The J2EE engine fails to find the FusionReactor JDBC Driver Wrapper (ClassNotFoundException).
- The J2EE engine finds the FusionReactor JDBC Driver Wrapper but the wrapper cannot find an in-memory accessible instance of the FusionReactor system; in which case the wrapper will degrade to logging to the console.
- The J2EE engine finds the FusionReactor JDBC Driver Wrapper, and the wrapper does locate an in-memory accessible instance of the FusionReactor system, but when attempting to send JDBC metrics to the system, encounters a class type mismatch (ClassCastException).
These symptoms occur mostly in situations where:
- FusionReactor has been deployed manually, or
- Customers are using third-party JDBC driver jars in JRun/ColdFusion, which previously had to have been copied to SERVER-INF/lib
The problem is due to the way J2EE engines partition their classloaders. The FusionReactor system filter must be loaded either at the same level of a classloader hierarchy as JDBC Driver Wrapper or a higher level. If this invariant is not satisfied, the exceptions mentioned above may be raised.
In the past, we have encouraged customers using ColdFusion to transition to third-party drivers, where their location and position within the classloader hierarchy can be fully controlled, and to install the jars for these drivers alongside the installed fusionreactor.jar. However, certain customers who are using Macromedia (Merant/Data-Direct) drivers are unable to move these drivers because of a licensing restriction imposed by the supplier of these drivers. This problem usually occurs in environments where ColdFusion has been installed as an EAR/WAR deployment within a J2EE engine.
We have resolved this issue by re-writing the interface between the FusionReactor system filter and the FusionReactor JDBC Driver Wrapper to be independent of classloader. As long as the FusionReactor system filter has been loaded by the same (or higher) classloader as the FusionReactor JDBC Driver Wrapper and subsequent wrapped driver, there should be no issues concerning communication between the two.
Third-Party (OEM) JDBC Driver Jars
It is no longer necessary to move third-party driver JAR files (e.g. MySQL Connector/J, JTDS etc.) to the SERVER-INF/lib folder. After updating the system fusionreactor.jar with the attached version, the The fusionreactor-jdbc.jar file should be installed in ColdFusion8/lib alongside the mysql-connector-java-* file. The wrapped datasource should then verify correctly.
Customers with FusionReactor 3.0.1 only should apply the attached Hotfix 1643. This consists of a new system fusionreactor.jar (with which you should replace your existing copy) and a new fusionreactor-jdbc.jar. This latter file should be placed in the same folder as your JDBC drivers.
- Hotfix 1623, described by technote
- Hotfix 1630, described by technote
- Hotfix 1635, described by technote
- Hotfix 1638, described by technote
- Hotfix 1640, described by technote
After installation, FusionReactor's "About" page should identify itself as Revision: 3.0.2, Build: FR-HEAD.1329.13132.
Hotfix FR 1643 – obf. (Stream: trunk, build 1329, SVN 13132)