If there are libraries you require both inside and outside tomcat, you could consider placing them in /jre/lib/ext. They are then available to all java applications using the particular JRE instance, including tomcat. For pre 1.4 versions, I found this useful for things like JSSE and regular expressions.
Andy. -----Original Message----- From: Dave Ford To: Tomcat Users List Cc: [EMAIL PROTECTED] Sent: 08/12/2002 20:38 Subject: Re: Tomcat shared libraries > Now the problem is this: Tomcat doesn't use libraries from anywhere but > within its scope. 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. > * 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? Dave Ford Smart Soft - The Developer Training Company http://www.smart-soft.com ----- Original Message ----- From: "Herrick, Rick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 10, 2002 7:29 PM 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. > > > 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]>
