RE: Tomcat shared libraries
-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
RE: Tomcat shared libraries
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
Re: Tomcat shared libraries
On Sun, 8 Dec 2002, Dave Ford wrote: Date: Sun, 8 Dec 2002 12:38:31 -0800 From: Dave Ford [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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. 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. * 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. Dave Ford Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
Re: Tomcat shared libraries
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
RE: Tomcat shared libraries
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 9:42 PM To: Tomcat Users List Subject: Re: Tomcat shared libraries 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). I can see why the problem has vanished, but it's like saying that you never get athlete's foot now that you've cut your legs off. Instead it solves the problem by cordoning off a whole area of functionality that's actually vitally important to many people who have to integrate web applications into a broader context. It is NOT an acceptable recourse to have to install ALL libraries into the Tomcat installation. I mean, for example, if Apache required you to install Tomcat into the Apache installation directory to integrate Tomcat into Apache, you'd be understandably peeved. That's essentially the situation with Tomcat now. It's fine for web applications that basically stand-alone, but more and more that is NOT going to be the context in which they operate. Furthermore, I've noticed the existence of a whole other class of question involving Why can't my web application find my properties, jar, or class file? You may get less of those questions than you did with classpath, but it seems like a case of cutting off your nose to spite your face. By the way, symlinks are the right answer to your dilemma (from common/lib to wherever the legacy JAR files are. Like I said, that's NOT a workable solution, since the majority of our installations run on Windows platforms that don't support symlinks in the manner that Unix does. So I was correct in my original assumption, which is that this is mainly an arbitrary design decision. If so, then it's a VERY bad one that doesn't really consider development outside of the Tomcat space or interlocking development between web apps and non web apps. It basically puts users in the position of having to rewrite core Tomcat scripts for each different application they create, which is both ugly AND non-extensible. Consider, for example, someone who has a Tomcat system already configured. We have to create a batch file that essentially overrides their existing configuration. That can either break the installation or cause the customer to have to go through a process of integrating our settings with their existing settings. The best solution would be one in which the ability to create an extensible class path was switchable and perhaps was off by default. E.g. CATALINA_USE_SYSTEM_SETTINGS (I like verbose env var names now that you don't normally blow the environment space with them :^) would be set to false by default. If it was true, then it would use system settings for CLASSPATH, etc.
RE: Tomcat shared libraries
See intermixed. On Wed, 11 Sep 2002, Herrick, Rick wrote: Date: Wed, 11 Sep 2002 08:46:18 -0700 From: Herrick, Rick [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: Tomcat shared libraries -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 10, 2002 9:42 PM To: Tomcat Users List Subject: Re: Tomcat shared libraries 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). I can see why the problem has vanished, but it's like saying that you never get athlete's foot now that you've cut your legs off. Instead it solves the problem by cordoning off a whole area of functionality that's actually vitally important to many people who have to integrate web applications into a broader context. It is NOT an acceptable recourse to have to install ALL libraries into the Tomcat installation. I mean, for example, if Apache required you to install Tomcat into the Apache installation directory to integrate Tomcat into Apache, you'd be understandably peeved. That's essentially the situation with Tomcat now. It's fine for web applications that basically stand-alone, but more and more that is NOT going to be the context in which they operate. Tomcat gets around 100k downloads per month from the main Apache web site (plus unknown numbers of redistributions). Of the downloaders, a majority are Windows users. Of those, a majority are still on Win98 (often installing Tomcat on their home PCs to learn about it). Successfully using the CLASSPATH (required by Tomcat 3.2.x) requires the ability to perform all of the following tasks correctly: * Edit the syntax of your set CLASSPATH command flawlessly (we're talking about users who typically have never seen a batch script before). * If you do this in your autoexec.bat file, you'd better also know how to edit config.sys to expand your environment space (as in a message thread just today from a 3.2 user). * If you have a very large number of JAR files or directories to include, it's still not going to work -- Windows imposes an upper limit on the length of an environment variable value. The failure mode symptoms when you hit this one can be very difficult to diagnose. You may be blessed with users for whom these sorts of things are not issues. Tomcat isn't. Furthermore, I've noticed the existence of a whole other class of question involving Why can't my web application find my properties, jar, or class file? You may get less of those questions than you did with classpath, but it seems like a case of cutting off your nose to spite your face. Over the last three years, about 95% of such reports are caused by not understanding the package structure of Java and how that has to be reflected in your internal directory or JAR structure -- thus, it's going to happen whether you use a CLASSPATH or not. The other 5% were legitimate bugs in the classloaders of various Tomcat versions that have since been fixed. If this feature truly didn't work, there would be zero Struts applications that run on Tomcat (Struts happens to rely heavily on this sort of thing). And that's clearly not the case ... By the way, symlinks are the right answer to your dilemma (from common/lib to wherever the legacy JAR files are. Like I said, that's NOT a workable solution, since the majority of our installations run on Windows platforms that don't support symlinks in the manner that Unix does. So I was correct in my original assumption, which is that this is mainly an arbitrary design decision. If so, then it's a VERY bad one that doesn't really consider development outside of the Tomcat space or interlocking development between web apps and non web apps. It basically puts users in the position of having to rewrite core Tomcat scripts for each different application they create, which is both ugly AND non-extensible. Consider, for example, someone who has a Tomcat system already configured. We have to create a batch file that essentially overrides their existing configuration. That can either break the installation or cause the customer to have to go through a process of integrating our settings with their existing settings. Not arbitrary .. deliberate. Messing with CLASSPATH is not something that any Java developer should have to worry about (it's one of the worst features of the platform) -- and the direction of recent changes in the platform itself (creation of the extensions facility in $JAVA_HOME/jre/lib/ext, the Class-Path attribute on MANIFEST.MF files in JARs, the design goal for webapps that they should be self-contained in the first place, and so on) imply that Tomcat is in the mainstream on this topic
Re: Tomcat shared libraries
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. 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]
