tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Tomcat 4.01 classloader problem?
Date Mon, 03 Dec 2001 16:44:47 GMT


On Mon, 3 Dec 2001, Marx, Mitchell E (Mitch), ALSVC wrote:

> Date: Mon, 3 Dec 2001 08:19:13 -0500
> From: "Marx, Mitchell E (Mitch), ALSVC" <mmarx@att.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: RE: Tomcat 4.01 classloader problem?
>
>
> As it seems a whole lot of people keep coming back to the classloader, I
> have a few questions in general.
>
> 1) Tomcat seems to be taking a pretty self-centered view of the world, in
> that any libraries it needs must be installed in one of it's pre-designated
> directories. Why is that?  I'm guessing for sake of the Tomcat code, not the
> Tomcat user.  It also goes against standing practices:
>
> 	a) The JAVA_HOME/jre/lib/ext directory for placing JAR files,
> 		From what I have read, Tomcat has a problem if things ARE
> placed there? (like servlet.jar)
> 	b) Oracle JDBC driver is a .zip, not a .jar and not usually
> installed "inside" Tomcat

Tell that one to Oracle -- they persist in doing the wrong thing.

> 		Yes, I have heard the solution of creating the symbolic
> link, but this is clumsy.
>

First, historical experience with many years of Apache JServ and Tomcat
users shows that using either CLASSPATH or the Java System Extensions
directory ($JAVA_HOME/jre/lib/ext) caused the second highest volume of
user problem reports (exceeded only by configuring web connectors).
These problems totally went away, once users understood how the new scheme
works (dump a JAR in the right place).

Second, neither CLASSPATH nor the system extensions directory gives you
enough control over the exposure of a particular JAR file to portions of
the container, or being able to mask it with a different version in a
controlled manner -- it's an all or nothing decision.

Third, most users are totally mystified by things like the following
scenario:
* Shared class loaded from system extension directory
* Application class loaded from WEB-INF
* Shared class tries to dynamically load application class (by name)
* ClassNotFoundException

Fourth, most users don't understand the security ramifications of putting
things in the system extensions directory -- these classes get all
permissions even if you are running under a security manager.

Fifth, putting things like servlet.jar in the system extensions directory
makes it totally impossible to support more than one version of the
servlet API on the same JVM -- you can have one and only one copy.

> 2) Can/Should there be a command line option to Tomcat:
> 	a) boolean to indicate use the CLASSPATH (default to false)
> 	b) define the classloader (like java.security.manager)
> 	c) add jar or ZIP files, or directories, to each part of the
> classloader (ie. add JDBC driver to common classloader)
>
> I am currently porting my application from WebLogic.  They dropped the whole
> CLASSPATH vs weblogic.class.path due to this class loader confusion.
>
> And I am quite aware of the "If you don't like it, change it" policy; just
> trying to feel some people out on the topic.  Perhaps this question is
> better served on the tomcat-dev mailing list, but I do still consider myself
> a "newbie".
>

It's been discussed on both the developer list and user list many times
before.  You're perfectly free to set up your own environment the way you
want -- you're also perfectly free to support it yourself.  As a
*volunteer* answering questions on this list (as well as a primary
developer of Tomcat 4), I'm not going to touch questions from people who
do this to themselves -- I've seen way too many people get totally burned
by classpath problems over the last five years.

> Thanks for listening.
>
> Mitchell Evan Marx        mmarx@att.com
> AT&T IP Network Configuration & Provisioning Development
>

Craig


--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message