You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jacob Kjome <ho...@visi.com> on 2003/01/28 19:50:42 UTC
Re[2]: [BULK] - Tomcat 4x Classloading
Hello Sankaranarayanan,
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.
So, if your webapp is actually seeing something set on your system
classpath, then that would be a huge bug in Tomcat as it is designed
to insulate your apps from the classpath entirely.
Jake
Tuesday, January 28, 2003, 12:37:32 PM, you wrote:
SGG> Has anybody seen this as well?
SGG> Any response will be greatly appreicated!
SGG> Thanx
SGG> Ganesh
SGG> -----Original Message-----
SGG> From: Sankaranarayanan (Ganesh) Ganapathy
SGG> Sent: Monday, January 27, 2003 5:56 PM
SGG> To: tomcat-user@jakarta.apache.org
SGG> Subject: [BULK] - Tomcat 4x Classloading
SGG> Hi All,
SGG> It has been my observation that the system CLASSPATH classes are loaded in precedence to the web application class files. i.e if I had a web application class file in my CLASSPATH and well as my
SGG> web application class repository (WEB-INF/classes) - the one in the system CLASSPATH is what is loaded.
SGG> I looked at the source of the web application class loader - I see that the system classloader is first given a chance to find the class file - to prevent the user from overriding the standard
SGG> J2SE classes.
SGG> This is contrary to what the documentation in the apache site says. I have included the relevant portions with this mail.
SGG> Am I missing something here?
SGG> --Ganesh
SGG> When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking.
SGG> All other class loaders in Tomcat 4 follow the usual delegation pattern.
SGG> Therefore, from the perspective of a web application, class or resource loading looks in the following repositories, in this order:
SGG> * /WEB-INF/classes of your web application
SGG> * /WEB-INF/lib/*.jar of your web application
SGG> * Bootstrap classes of your JVM
SGG> * System class loader classses (described above)
SGG> * $CATALINA_HOME/common/classes
SGG> * $CATALINA_HOME/common/endorsed/*.jar
SGG> * $CATALINA_HOME/common/lib/*.jar
SGG> * $CATALINA_HOME/shared/classes
SGG> * $CATALINA_HOME/shared/lib/*.jar
SGG> --
SGG> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
SGG> For additional commands, e-mail: <ma...@jakarta.apache.org>
SGG> --
SGG> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
SGG> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Jacob mailto:hoju@visi.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: [BULK] - Tomcat 4x Classloading
Posted by Jacob Kjome <ho...@visi.com>.
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> (willh@msoft.com)
WH> --
WH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
WH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Jacob mailto:hoju@visi.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[2]: [BULK] - Tomcat 4x Classloading
Posted by Will Hartung <wi...@msoft.com>.
> 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.
No Jacob, that's not true.
Classes within the Tomcat container have full visibility of the system
classpath. The startup scripts, however, ignore the CLASSPATH environment
variable on start up which gives the illusion that Tomcat is not seeing
those classes.
The reason it's not seeing those classes is because of the actions of the
startup script, not because of the Tomcat container itself. All of the
classloaders descend from the original classloader used to fire up the
Tomcat bootstrap.
So, if you start Tomcat up without the provided scripts, or change the
scripts to manipulate the CLASSPATH for the JVM, your classes will be able
to see those classes.
Regards,
Will Hartung
(willh@msoft.com)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>