At 01:58 PM 3/1/2002 +0000, Monika Solanki wrote:
>yes, I am using tomcat but which is bundled with the java webservices pack which also
>has a common \lib. I want to put the axis.jar, log4-core.jar and xerces.jar in the
>path. Can I put it in that directory?
>
>Cheers.
Answer #1: try it and see if it works.
Answer #2: There are two factors: one is basic visibility, what I usually call
"being on the classpath", and the other is the confusion of being in a hierarchy
of "classloaders", and I wish I understood this better, but...
A jar can get on the classpath by being on the environment variable CLASSPATH,
and you can see if it's there by saying, f'rinstance,
System.getProperty("java.class.path");
But running within Tomcat 4.01, I see my java.class.path property contains only
java.class.path=C:\tomcat401\bin\bootstrap.jar
because most things are loaded by a classloader which looks in various directories;
tomcat/lib, tomcat/common/lib, your webapp's WEB-INF/lib (and the corresponding
"classes" directories, but you were talking about jars.) If it is asked for a class
and it doesn't have that class, it will ask its parent classloader.
The normal image seems to be that you put your code as local as possible, e.g.
in your WEB-INF/lib, and it can call on code that's up in the hierarchy (say, in
tomcat/common/lib) which can call on code above it (say, in the lib/ext directory
below your java.home property, or in sun.boot.class.path). Think of each classloader
as extending the language a little, and then a classloader below it is one possible
extension based upon it...but a classloader cannot call upon a sibling or child,
so it is perfectly possible to have class A visible to class B which is not
visible to class A. In particular, if you write XSL extension functions as part of
your webapp and you want to put them in your WEB-INF/lib, you may have trouble
because (I _think_, and I hope that somebody who really deep-down understands this
will correct me if I'm wrong) the stuff in your WEB-INF/lib can see above it (e.g.,
see Xalan if that's in common/lib) but it is not visible to the XSL processor
unless you put Xalan down into your WEB-INF/lib, in which case of course you may
be loading more than one Xalan at a time...and they won't see each other. What I'm
sure of there is that I've had trouble with visibility which has usually been fixed
by flattening out the hierarchy, so at the moment I mostly put things into common/lib.
I hope that #2 makes sense...I hope it's mostly true...I hope #1 is adequate, anyway.
:-)
Tom Myers
