Ok, the problem is my misunderstanding of the process here. I thought
WebAppClassLoader always checked WEB-INF/lib before delegating; I see that
it actually delegates to the System loader first, then checks WEB-INF/lib,
and finally delegates to its own parent. So my comment earlier about "they
can'
On 17.06.2010 16:37, Konstantin Kolinko wrote:
2010/6/16:
Looking at section 10 of the 6.0 user guide, which describes classloading,
the text makes perfect sense and matches the way I understand things work.
However the summary at the end of the section "Class Loader Definitions"
looks wrong; i
2010/6/16 :
>
> Looking at section 10 of the 6.0 user guide, which describes classloading,
> the text makes perfect sense and matches the way I understand things work.
> However the summary at the end of the section "Class Loader Definitions"
> looks wrong; it basically says that the search order
"Caldarale, Charles R" wrote on 06/16/2010
09:55:19 PM:
> > From: peter_f...@blm.gov [mailto:peter_f...@blm.gov]
> > Subject: Re: Tomcat 6.0 documentation: is classloading description
> > correct?
> >
> > The docs say in one place that the order is one
> From: peter_f...@blm.gov [mailto:peter_f...@blm.gov]
> Subject: Re: Tomcat 6.0 documentation: is classloading description
> correct?
>
> The docs say in one place that the order is one way (WebApp
> first, then Boot, System and Common, which is as I'd expect)
Please
When I wrote "CLASSPATH" I meant the classpath value that's built up by the
catalina.sh - I'm well aware that it creates this from clean. I think
you're missing the point; CLASSPATH is used to set the System classloader's
search path, sure - but the question is where that loader fits into the
loade
Use "Class Loader Definitions" carefully,
System - This class loader is normally initialized from the contents of the
CLASSPATH environment variable.
All such classes are visible to both Tomcat internal classes, and to web
applications. However, the standard Tomcat 6 startup scripts
($CATALI
