> 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.
If Java has one significant paradigm blip that throws EVERY body, it's the CLASSPATH. 99.99% of problems folks seem to encounter is a problem with the CLASSPATH. So just to be clear, I always thought that TC 4 pretty much completely ignored the system CLASSPATH variable, and built its own classloaders up from scratch. But, I see now, that's only done within the Tomcat startup scripts, not within the application itself. So a little script surgery and we can do "anything we want". Cool. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
