> 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]

Reply via email to