tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Re: Tomcat 6 unstable
Date Tue, 25 Nov 2008 03:51:33 GMT
> From: Michael Ludwig [mailto:milu71@gmx.de]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message