> -----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.
