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. > 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. > That just gets people back in trouble again, but you're welcome to do that to your own copy. Another alternative to consider is to build your own Tomcat launcher that sets up the class loader hierarchy the way that you want it (you can base this on org.apache.catalina.startup.Bootstrap) and then invokes the rest of the startup procedure that reads server.xml and so on. You could arrange that your software installation processes set up the configuration for this when your products are installed, so that the list is always up to date. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
