> -----Original Message-----
> From: Mario Felarca [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 11, 2002 7:40 PM
> To: [EMAIL PROTECTED]
> Subject: Tomcat 3.3a - classloader hirearchy questions
>
>
> Hello, I had a problem a few days ago with Tomcat 3.3a and
> loading classes
> that I have tracked down. I wanted to ask if my understanding of the
> classloader hirearchy is correct or if there are other people
> that have
> experienced similar behavior.
>
> I was running Tomcat 3.3a as a service, and on the
> -Djava.class.path was
> tomcat.jar and one other directory that had a copy of one of
> my classes,
> we'll call it Base1.class.
>
> Now, Base1.class was also in a jar that I had put in
> tomcat/lib/apps and
> was thus loaded by the apps classloader. The problem I was
> running into,
> was that I had another class in that same jar, loaded by the apps
> classloader, that extended from Base1.class. We'll call this class
> SubClass1.class.
>
> I expected SubClass1.class to load Base1.class from the apps
> classloader,
> since they were both in the same jar. What appeared to be
> happening, was
> that SubClass1.class was attempting to load Base1.class from
> the system
> classloader. Here, Base1.class got loaded (since there was a copy on
> -Djava.class.path) but since Base1.class needed to load other
> classes that
> were not on the system classloader, things failed out.
>
> I know that a solution is to remove the copy of Base1.class from the
> -Djava.class.path location, but now I am curious as to if my
> understanding
> of the classloaders is incorrect.
>
> Shouldn't the SubClass1.class look for any classes that it is
> dependent on
> in the same classloader first? In this case it would be the apps
> classloader which should also have loaded Base1.class.
>
> Or, does the apps classloader not load Base1.class since it
> was already on
> the -Djava.class.path?
>
> Better yet, is this a configuration issue that I have simply
> overlooked?
Tomcat 3.3 follows the JDK implementation for classloaders
where child classloaders delegate to their parent classloaders
first, before attempting to load a class themselves. This is
why Base1.class is found in the CLASSPATH classloader even though
it exists in other classloaders in the chain.
Per the Servlet 2.3 spec, Tomcat 4.x implements the classloader
behavior differently. Classloaders may attempt to load the
class first before delegating to their parent classloader.
In this case, your scenario would have worked.
>
> Finally, I noticed that if I ran from the tomcat batch file,
> and set the
> CLASSPATH environment variable to be the same as the
> -Djava.class.path
> parameter that I used, the behavior was different and I did
> not get the
> same problems as I did when running as a service.
>
> Any information or ideas would be appreciated.
>
> Thanks so much in advance,
>
> Mario-
>
>
>
> _________________________________________________________
>
> Do You Yahoo!?
>
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
