At 01:12 PM 6/19/2001 -0400, Matthew J. Duftler quoted a Tomcat faq
>...
>A: All you need is a correct version of JDK (1.1.x or 1.2).
>
> Since the JSP engine also uses 'javac' it needs to be in the CLASSPATH.
> If you are using JDK 1.1.x it will automatically be included. If
> you are using JDK 1.2 you will need to set JAVA_HOME to the directory
> where JDK is installed or alternately you can put "tools.jar" in your
> CLASSPATH.
I wish that classpaths didn't have to come up in a soap-user list at all,
but this seems to be the most common source of introductory problems and
there is sometimes something more subtle & nasty going on somewhere.
In my co-author's Win2000 setup of Tomcat, as on Dylan's, "tools.jar" was
definitely on the classpath (twice)...but javac.Main was still not
found until tools.jar went into jre/lib/ext, after which there was no
problem. That's a little bit scary:
Sometimes the classpath is not enough to make things work.
My guess is it's a multiple-classloader issue as discussed, e.g., in
http://members.spree.com/education/developergrp/code/dynamic.htm
>"...Multiple ClassLoaders will defeat the static-ness of fields
>across the same version of the same class over multiple ClassLoaders,
>much to the surprise of most Java developers.
>Unfortunately, this has some frightening implications: it means, most of
>all, that Singletons really aren�t Singletons, either. ....
>
>The best solution, then, is to simply be aware of this, and try
>whenever possible to make sure that Singleton classes (like
>DatabaseManager) get loaded as far up the ClassLoader tree as
>possible. Fortunately, this is a problem that won�t rear its
>ugly head very often, and is usually pretty quickly solvable
>(Drop the . jar file into the jre/lib/ext directory) in most
>environments.
but opposed to this advice are Craig McLanahan's remarks at
http://perl.jann.com/tomcat/200103/msg01657.html
>..............................let's look a little at how class loading
>actually works in Tomcat (the details do ***not*** necessarily apply to
>any other servlet container, because standard behavior is not specified).
>There is actually a hierarchy of class loaders created when Tomcat is running:
>- Bootstrap class loader (Java system classes)
>- Extensions class loader (JAR files from $JAVA_HOME/jre/lib/ext)
>- System class loader (contents of CLASSPATH at startup time)
>- Webapp class loader (contents of WEB-INF/classes and WEB-INF/lib
> for your particular web application)
and he explains how class loading can move up but not down the tree and
thus lead to surprising ClassNotFoundException cases in servlets, and says
>* Do not rely on system extensions in $JAVA_HOME/jre/lib/ext. If you
> do, those classes are *not* allowed to reference any classes on the
> system class path, or inside your web application.
>* Do not rely on adding classes onto your CLASSPATH (or putting them in
> $TOMCAT_HOME/lib) before starting Tomcat. Such classes will have
> problems with downward references, as described above. Also, support
> for shared library classes is ***not*** required by the servlet spec,
> so you cannot count on this facility in a portable app.
>* Put all classes your application needs into WEB-INF/classes, or
> in JAR files unde WEB-INF/lib. In this way, they will all be loaded
> by the same class loader and not have any referencing problems.
I'm really not sure. All that I am sure of is that sometimes being on
the classpath is not enough to make things work. (On the other hand,
on NT 4.0 week before last I gave up on lib/ext altogether and put
everything I absolutely needed on the classpath, one at a time. Dropping
the same files into lib/ext did not work, even though I could not find
any conflicts. I got it going, and fortunately one of the students
brought in an NT laptop and another a Win9x laptop so I could show
the main variations..it worked, but I was and am bewildered. I
would really like to have a good conceptual model of this, presumably
starting with what McLanahan's talking about, and if somebody out
there can point to a document which describes it then (a) I'd be very
grateful, and (b) I suspect that the SOAP docs, and every other such
project where these questions come up so often, should point to that
document just as a timesaver.
Tom Myers
