Hi Jake,
Appreciate you writing back.
The tomcat class loader heirarchy is thus
sun.misc.Launcher$ExtClassLoader (refers to the lib extensions)
^
|
sun.misc.Launcher$AppClassLoader (refers to system classpath)
^
|
org.apache.catalina.loader.StandardClassLoader ( refers to common repository)
^
|
org.apache.catalina.loader.StandardClassLoader (refers to shared repository)
^
|
org.apache.catalina.loader.WebappClassLoader (refers to the web app repository)
I dont understand how you can claim that the CLASSPATH is never referred.
My question is about the order of reference. I thought the web app repository was the
first thing always refferred by the WebAppClassLoader - but my tests and the code from
WebAppClassLoader seem to point out that the System Classloader
(sun.misc.Launcher$AppClassLoader ) is first given a chance to find the class to avoid
overriding the J2SE classes. That being the case my contention is tomcat documentation
on the same is wrong.
Thanx
Ganesh
-----Original Message-----
From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:51 AM
To: Tomcat Users List
Subject: [BULK] - 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: [EMAIL PROTECTED]
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: <mailto:[EMAIL PROTECTED]>
SGG> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
SGG> --
SGG> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
SGG> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
