Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Date: Thu, 13 Jul 2000 07:17:07 -0700
From: Alex Chaffee <guru@edamame.stinky.com>
To: tomcat-dev@jakarta.apache.org
Subject: Re: What Do We Do With The User's Classpath?
Message-ID: <20000713071707.C12912@edamame.stinky.com>
Reply-To: alex@jguru.com
References: <396E0B43.A7B1445E@eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <396E0B43.A7B1445E@eng.sun.com>;
 from Craig.McClanahan@eng.sun.com on Thu, Jul 13, 2000 at 11:32:35AM -0700

I *love* Ian's suggestion to use an environment variable, custom to
Tomcat.  I think it answers all questions.

One suggestion: call it TOMCAT_CLASSPATH just so there's no confusion
(what does "PRELOAD" mean in this context?)

or maybe TOMCAT_CLASSPATH_EXTRA but I think that's pushing it.


>     *   If you have your own JAXP-compliant parser
>         on your classpath, for example, it will not be
>         used -- Tomcat will default to the JAXP reference
>         implementation that is bundled -- unless you
>         remove the "jaxp.jar" and "parser.jar" files from
>         $TOMCAT_HOME/lib.

Isn't JAXP configurable by system properties?  

export TOMCAT_OPTS=-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.whatever

(or set TOMCAT_OPTS=... )

(in the appropriate AUTOEXEC.BAT or .bash_profile or whatever)

will render this complaint moot.  That is, the above is a
well-documented way to tell JAXP to use a parser regardless of
classpath ordering.  (Note: I haven't tried it myself.)


>     *   If you have incompatible versions of some of
>         the libraries that Tomcat needs on your class
>         path, Tomcat will still work -- because it will
>         find the Tomcat libraries first.

This issue is very important -- we need to be sure that

(a) Tomcat finds its preferred versions of classes when it's running

(b) user webapps find their preferred versions when they're running

I beleive that AdaptiveClassLoader takes care of this, by putting the
webapp/lib/*.jar and webapp/classes *ahead* of the system classpath,
while in the context of the webapp, but not while in the context of
Tomcat.  

I'm very shaky on the whole classloader issue -- can someone confirm
that I've just described its actual behavior?  Craig did imply that
that's how it really works...


> 3)  The user's existing class path should be
>     ignored, and *only* the libraries in
>     $TOMCAT_HOME/lib should be used.

This seems safest and cleanest.  Especially considering the two
environment variables discussed above.

Users can either add jars to TOMCAT_HOME/lib, or add them to
TOMCAT_CLASSPATH, and be assured they'll be found first.  But this
should not really be happening that often, given that webapps (to be
portable) should be including all dependencies inside their own
WEB-INF/lib directory.


>     *   This is philosophically similar to the Java2
>         "extensions" mechanism, where JAR files
>         placed in a particular directory are automatically
>         added to the class path.  This can be good news
>         or bad news (it's easy to forget that old versions
>         are there).

This is kind of misleading, since extensions are special and magical
and have other weird effects on classpath priority.  For instance,
I've noticed that having ant.jar in jre/lib/ext breaks org.xml.sax.*
classloading somehow... (?!?!!)

>     *   If you want to use a particular JAR file inside
>         Tomcat and in other Java applications, you need
>         to duplicate it (in $TOMCAT_HOME/lib), which
>         risks being out of sync with other copies of that
>         same library.

We should recommend against this, for that reason, in favor of the
WEB-INF or TOMCAT_CLASSPATH options.


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/