Caldarale, Charles R schrieb am 24.11.2008 um 19:52:22 (-0600): > You must not place a jar in multiple locations that are visible along > any single branch of the classloader hierarchy. Look at the diagram > and discussion here: > http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html > > Bootstrap > | > System > | > Common > / \ > Webapp1 Webapp2 ... > > Since the jre/lib/ext directory is essentially part of the > Bootstrap class loader, you now have three locations that the DB2 > JDBC driver might be loaded from. This pretty much guarantees > class loading conflicts that will result in all sorts of problems, > including NoClassDefFoundError, and many other more subtle issues.
This is starting to sound like DLL Hell. > To use Tomcat's DB connection pooling, the jar needs to be in > either the jre/lib/ext or the CATALINA_HOME/lib location - not > both. It cannot be in WEB-INF/lib to use Tomcat's connection > pooling, but it can be there if you use your own pooling (or no > pooling at all), in which case it must be removed from the other > two places. Could web app Foo, which brings its own DB2 driver - in spite of the same driver already offered by the common.loader or the bootstrap.loader, by this very fact jeopardize other web applications running in the same container, which rely on the DB2 driver offered by the "common.loader"? Or would web app Foo only harm itself? Does this mean web apps have to be monitored for the classes they make available in order to make sure none of them has already been made available via the common.loader? Michael Ludwig --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
