Tomcat 3.2 used CLASSPATH the way you are asking for. It resulted in CLASSPATH problems being the second largest catecategory of user problems (behind configuring web connectors, but only barely).
Tomcat 3.3 and 4.x ignore CLASSPATH, and this category of user problems has basically vanished. Sounds like a smart move to me (especially since that was my choice, and I've adamantly resisted the idea of regressing back ever since). By the way, symlinks are the right answer to your dilemma (from common/lib to wherever the legacy JAR files are. Craig McClanahan On Wed, 11 Sep 2002, Herrick, Rick wrote: > Date: Wed, 11 Sep 2002 05:29:12 +0200 > From: "Herrick, Rick" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Tomcat shared libraries > > I'm currently in the process of developing a web application with Tomcat as > the default reference platform. Although we'll support running with BEA, > JRun, etc., our installer app will install and modify settings only if > you're installing for Tomcat. I have to make a decision on how to proceed > with our installer and really need to understand this problem. > > Now the problem is this: Tomcat doesn't use libraries from anywhere but > within its scope. That is, it ignores the system classpath in its default > configuration. I've read the class loader how-to (which isn't really a > how-to, but whatever), and also worked with it for quite some time, so I > understand pretty well how it works. Basically your classes and JARs need > to be placed somewhere within the context of Tomcat: WEB-INF\classes, > WEB-INF\lib, $CATALINA_HOME/common/classes, > $CATALINA_HOME/common/endorsed/*.jar, $CATALINA_HOME/common/lib/*.jar, > $CATALINA_HOME/shared/classes, and $CATALINA_HOME/shared/lib/*.jar. > > The problem is that this is a strictly web app-centric view of the world. > In fact, many of the libraries that we need to use from within our web app > are standard class libraries that other non-web applications need to use, > such as our main server product, our non-web client applications, > development tools, and so on. This leaves me three choices: > > * Replicate the libraries in two places, one for non-web apps and one for > web apps (this solution, BTW, has to be cross-platform capable, so using > links is out). This is less than desirable because of the maintenance > problem with controlling versions. > > * Place the primary libraries within the Tomcat context and refer the other > applications to that location. This doesn't work both for legacy and > upgrade reasons (i.e. if you've already got a server installed, it expects > to find its support libraries in a particular place and not have them moved > over to another location) and because it's nonsensical for a non-web-based > application to refer to an app server's repository. > > * Mung around with the batch files and add the required directories to the > classpath for Tomcat. > > I do the third. This works just dandy: my required libraries remain in > their central product-centric location, everyone can find what they need, > and there's only one version of the libraries around (well, it's a > development machine, so of course there's about 10 versions of every library > around, but *I* know where they are :^). > > I browsed through the archives of this list and found the following quote: > > From > http://www.mail-archive.com/[email protected]/msg64144.html: > "How do I add an existing jar to a servlet's classpath, if that jar doesn't > want to live under WEB-INF/lib? (I ultimately asked this here, and got a > solid "you can't" response, so I'm satisfied. However, I've seen this asked > here often, so it'd make a great FAQ submission."--Paul Brinkley > > My question is, why is this so? Why is it that "you can't"? Since I know > you can in practice (by setting the CLASSPATH sometime after > setclasspath.bat nukes the system classpath or by removing setclasspath.bat > altogether), the prohibition seems arbitrary. Is there a security issue > with Tomcat doing class loading outside of the Tomcat context? It seems to > me that it's mainly due to a provincial view of a web app as a > self-contained entity, but in reality most of the people I know writing web > apps nowadays are running into *exactly* this sort of issue again and again. > > > So to make our installer work, at this point I'm actually moving the > existing setclasspath.bat file to some tmp name and creating a new one that > sets the CLASSPATH to what we need. Is there any problem with this other > than it's not cool to monkey with another product's settings? > > Thanks for getting through all this! Any help or explanation is greatly > appreciated. > > Rick Herrick, senior software engineer > CIS/TM > (303) 362-4892 > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
