I understand. And it makes sense. But... I agree that monkeying around with the system classpath is not the optimal solution!
But, that's what i thought the classpath section was for in tomcat.properties. So, exactly what is/does this section do? It seemed like a great way to add additional classpaths for more advanced needs. # CLASSPATH environment value passed to the JVM # Syntax: wrapper.classpath=[path] (String) # Default: NONE (Sun's JDK/JRE already have a default classpath) # Note: if more than one line is supplied these will be concatenated using # ":" or ";" (depending wether Unix or Win32) characters. JVM must be # able to find JSDK and JServ classes and any utility classes used by # your servlets. # Note: the classes you want to be automatically reloaded upon modification # MUST NOT be in this classpath or the classpath of the shell # you start the Apache from. # wrapper.classpath=@JSERV_CLASSES@ wrapper.classpath=@JSDK_CLASSES@ wrapper.classpath=@HPMS_CLASSPATH@ -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thu, August 08, 2002 13:47 To: Tomcat Users List Subject: RE: Howto add shared libs to tomcat's classpath? On Thu, 8 Aug 2002, SHURTLEFF,ROBERT (HP-FtCollins,ex1) wrote: > Date: Thu, 8 Aug 2002 12:27:30 -0700 > From: "SHURTLEFF,ROBERT (HP-FtCollins,ex1)" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Howto add shared libs to tomcat's classpath? > > We have several 3rd party products that install onto the same machine are > are used by other applications than just tomcat. > > These apps install themselves into their expected locations, etc. They are > also nice enough to add an env setting for their classes/jars. > > These are primarily middleware services for our platform. > > Some webapps also need access to these jars. > > We don't want to duplicate the jars into multiple locations. > > There should be an easy way to extend tomcats classpath. > Here's two easy ways: * Create symbolic links from Tomcat's common/lib directory to your previously installed modules. * Modify the startup script logic that calculates the CLASSPATH environment variable. A little historical perspective might be illuminating about why Tomcat doesn't provide an "easy way" to do this. Up to and including Tomcat 3.2, messing around with CLASSPATH was the only way to add JARs, because there was no such thing as a directory like common/lib to put them in. Fully 50% of the requests for help on the TOMCAT-USER list were from people who were screwing around with CLASSPATH and getting the syntax wrong, or otherwise messing up their Java environments becaues they didn't know what they were doing. Tomcat 3.3 and 4.x releases both follow the pattern of giving you a directory to dump shared JARs into (or link to them on an operating system that supports symlinks). Since those releases, the percentage of problem reports has gone from 50% to around 2% -- and the only question nowdays is the one you ask (how to make additional JARs available) -- the problems people had about breaking the CLASSPATH for Tomcat, or for their other Java based applications, have gone totally away, because how it actually works is trivially simple to understand, and easy to deal with via drag-and-drop tools through a GUI. Bottom line -- if you want to manually modify your CLASPATH, you're welcome to do so, in your own copy of the startup scripts. But you're on your own if you screw it up. I'm not at all interested in going back to the bad old days, and I don't imagine anyone else who answers support questions on TOMCAT-USER would be very thrilled either. Craig -- 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]>
