Craig R. McClanahan wrote: > 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. >
There is one potential problem with using symlinks, they won't work with the Java SecurityManager for setting a security policy. Perhaps installing those jars in $JAVA_HOME/jre/lib/ext would work. That would be common across all the platforms. > 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/tomcat-user@jakarta.apache.org/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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
