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
