Hello Will, Thanks for the clarification.
So, if one starts Tomcat as an NT servive which doesn't run through a script, the system classpath will be fully seen by Tomcat? Ok, well, that still doesn't cause problems for me because I put next to nothing on the system classpath. I always make each program determine what it wants its classpath to be. I only put enough on the classpath to allow Jikes to work without having to provide tools.jar and such every time I want to run it. Jake Tuesday, January 28, 2003, 1:17:01 PM, you wrote: >> This shouldn't be true. Apps cannot see the system classpath at all. >> Only Tomcat sees that at startup. Webapps will only see classes in >> WEB-INF/lib, WEB-INF/classes, common/endorsed, common/lib, >> common/classes, shared/lib, and shared/classes. Tomcat, itself, also >> sees stuff in server/lib and server/classes. WH> No Jacob, that's not true. WH> Classes within the Tomcat container have full visibility of the system WH> classpath. The startup scripts, however, ignore the CLASSPATH environment WH> variable on start up which gives the illusion that Tomcat is not seeing WH> those classes. WH> The reason it's not seeing those classes is because of the actions of the WH> startup script, not because of the Tomcat container itself. All of the WH> classloaders descend from the original classloader used to fire up the WH> Tomcat bootstrap. WH> So, if you start Tomcat up without the provided scripts, or change the WH> scripts to manipulate the CLASSPATH for the JVM, your classes will be able WH> to see those classes. WH> Regards, WH> Will Hartung WH> ([EMAIL PROTECTED]) WH> -- WH> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> WH> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
