tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Tomcat 6.0 documentation: is classloading description correct?
Date Thu, 17 Jun 2010 15:49:39 GMT
On 17.06.2010 16:37, Konstantin Kolinko wrote:
> 2010/6/16<Peter_Ford@blm.gov>:
>>
>> 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 is...
>>
>> Bootstrap
>> $CLASSPATH
>> WEB-INF/classes
>> WEB-INF/lib/*.jar
>> $CATALINA_HOME/lib
>> $CATALINA_HOME/lib/*.jar
>>
>> ...when my understanding is it should be...
>>
>> WEB-INF/classes
>> WEB-INF/lib/*.jar
>> Bootstrap
>> $CLASSPATH
>> $CATALINA_HOME/lib
>> $CATALINA_HOME/lib/*.jar
>>
>> So, is the documentation just wrong, or have I misunderstood something?
>>
>
> The order is
>> Bootstrap
>> $CLASSPATH
>> WEB-INF/classes
>> WEB-INF/lib/*.jar
>> $CATALINA_BASE/lib
>> $CATALINA_BASE/lib/*.jar
>> $CATALINA_HOME/lib
>> $CATALINA_HOME/lib/*.jar
> as documented.
>
> Note, that many Bootstrap and $CLASSPATH classes are loaded at early
> stages of Tomcat startup sequence, that is before classloading
> hierarchy itself is created.   It would be a mess if those classes
> were ignored.
>
> That is why people should not play with $CLASSPATH, unless in certain
> very rare cases.
>
>
> If you have some documentation changes in your mind, the patches are
> welcome. The sources are in webapps/docs/*.xml  .  Create a Bugzilla
> issue and attach a diff file there (svn diff or an 'Unified diff'
> (diff -u)).

I guess part of the confusion comes from the terminology "parent" and 
"delegating".

The classloader used by the webapps is derived from the usual 
URLClassloader as an extension. In Tomcat land it's parent is the 
classloader that loads from the common lib directory.

The webapp classloader is "not delegating first" in the sense that it 
first tries to find classes via it's own super URLClassloader, before 
asking the parent common loader.

The URLClassloader in turn is the one, that first goes down to bootstrap 
and system/CLASSPATH before checking the configured URLs (WEB-INF). So 
in Tomcat terminology it's true, that the webapp classloader does only 
delegate (to common) if it can't find the class, but the webapp loader 
itself does delegate to bootstrap and system first.

(hope that's true and not too confusing ...)

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message