> From: Michael Ludwig [mailto:[EMAIL PROTECTED] > Subject: Re: Re: Tomcat 6 unstable > > This is starting to sound like DLL Hell.
A bit, but the advantage of a classloader hierarchy is that webapps are isolated from each other (a servlet spec requirement). If you keep the jars your webapp needs with the webapp and not scattered all over, you won't have a problem. Unfortunately, you can't do that if you want Tomcat to manage the DB connection pooling, since Tomcat itself must have access to the JDBC driver classes. You can always manage the pool inside the webapp yourself using commons-dbcp or the like. > 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? Good question, and it doesn't have a clear answer. If an object originating in a webapp classloader is passed to code from a more global classloader, and then another webapp accesses that object, it will not be castable to any type the second webapp has access to. (Class myPackage.MyClass loaded by classloader A is not the same type as myPackage.MyClass loaded by classloader B.) > 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? If a webapp minds its own business, there shouldn't be a problem. If it tries to use Tomcat's DB connection pooling (or logging, or some other shared mechanism), but insists on providing its own copy of the shared classes, then there are likely to be problems. (This is a problem with servlet containers - not just Tomcat - because it breaks the standard Java classloading model of always delegating upwards. As mentioned before, this breaking is pretty much required by the servlet spec.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]