> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 08, 2002 1:53 PM > > On Sun, 8 Dec 2002, Dave Ford wrote: > > Rick, I was reading your discussion with Craig McClanahan > and I agree > > with you - that a web app should be able to access classes > outside the > > tomcat folder. Copying class into catalina/shared for each > build is a > > pain (even with ant). Symlinks won't work on windows. Why couldn't > > tomcat add an entry into server.xml, to point to extra > class location? > > Orion has had this for a few years now. > > Before Tomcat went to the current policy of ignoring the > CLASSPATH variable (i.e. Tomcat 3.2), class path editing and > understanding problems were the #2 most popular issue on > TOMCAT-USER, because a very large percentage of newbies had > real problems with them. (What's #1? it remains problems > configuring the web server connector.) > > The current policy is straightforward and easy to understand, > and that whole class of problems has basically vanished. > That tells me the choice to be hard nosed was a good one.
Well, it's like saying that by banning all cars on the freeway we've done away with traffic jams. Yeah, you have, and that's pretty straightforward, but you've also really curtailed the options available. I understand why that was done, but it really cuts into the reusability of code libraries. I don't like having to copy our own libraries and 3rd party libraries into every installation of every web app that we create. And we create a number of them, meaning that you're really asking for version problems to bite you in the rear. > > > * Mung around with the batch files and add the required > directories > > > to the classpath for Tomcat. > > > > How exactly did you do this? What batch file? > > The standard startup script ($CATALINA_HOME/bin/catalina.sh or > $CATALINA_HOME/bin/catalina.bat) delegate to a separate > script (setclaspath.sh or setclasspath.bat) to set up the > system CLASSPATh and other related variables. You can > customize this as needed, but you're on your own for figuring > out class loader hierarchy problems, as well as things like > running out of environment space on Win98. If you look in catalina.bat (I'd imagine it's similar on *nix, but I'm not sure), there's a line near the end (in my 4.0 installation, it's line 173) that reads: rem Execute Java with the applicable properties Right before that, you can set your classpath there. You can go ahead and add "C:\Program Files\MyLibs\Shared\mylib.jar" there and so on (I had some trouble trying to use jar file that contained a manifest instead of directly adding the various libraries contained in the manifest; YMMV, and I didn't try to figure out if the problem was related to the manifest or some other environmental issue, since everything was kinda screwed up at that particular time). There's another alternative, though, which is to set the various Java options in the service configuration. This requires you to install Tomcat as a service and for obvious reasons is only valid on Windows (I haven't done this with Win98-type consumer systems, so don't blame me if it breaks there ;^). If you've already installed Tomcat and didn't install as a service, you can go ahead and just reinstall. Just make sure you back up modified conf and script files. Once you have Tomcat installed as a service, find the service config keys for the JVM parameters. Where these are located depends on whether you have 4.0 or 4.1 installed: 4.0: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache Tomcat\Parameters 4.1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache Tomcat 4.1\Parameters There are generally 3 or 4 values here that you're concerned with. The most important is the DWORD value "JVM Option Count." This tells the service on start-up how many options there are to pass to the JVM. The next ones are "JVM Option Number 0," "JVM Option Number 1," and so on. For 4.0 there are by default (I think this is pretty close): JVM Option Count: 2 JVM Option Number 0: -Djava.class.path=d:\tools\jakarta-tomcat\bin\bootstrap.jar; JVM Option Number 1: -Dcatalina.home=d:\tools\jakarta-tomcat Of course this changes based on your CATALINA_HOME.... So I just add all my classpath entries to the "JVM Option Number 0" setting and add other JVM options as I need them, e.g. I have "JVM Option Number 2" set to "-Djava.library.path=c:\ourprod\bin;c:\ourprod\3rdparty\bin;" to support the native code libraries for the product that I work on. I also have some debug flags set and other things like that. This works like a charm for me. It's also nice since I have staging and test servers that run remotely in California (I'm in Colorado). Since this is set up as a system service, I don't have to log in thru Terminal Services, start a session, start the catalina script, then disconnect the session. Instead, when I reboot the machine, the service comes up without any muss or fuss. One thing to be aware of though: if you use network-mounted drives (for example, one of the products I work on uses a shared folder called "D:\ThisProd," which is always mapped to T:\ for the build scripts and what not), the system parameters must be configured with the *physical* address, not the network mount. This is because the network drives aren't connected until you log in. Since this starts up before the login, those drives are unavailable. So when I want to use the thisprod.jar that comes in our development repository, I have to set the classpath to d:\OurCompany\ThisProd\Shared\thisprod.jar instead of t:\OurCompany\ThisProd\Shared\dfc.jar.
