You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ole Ersoy <ol...@gmail.com> on 2008/06/17 04:41:50 UTC
Class Loader Documentation
Hi,
Reading through the classloader documentation for 6.0 I noticed this:
...
However, the standard Tomcat 5 startup scripts
...
It seems like this should be:
the standard Tomcat 6 startup scripts
But I figured I'd check before filing a ticket.
Also it seems like this section could be simplified:
----------------------------------------------------------------
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.
----------------------------------------------------------------
So this seems to be saying that "normally" all classes that should be visible to both Tomcat and webapps are placed in the CLASSPATH environment variable. The second sentence seems to reinforce that placing the libraries in the CLASSPATH makes them visible to both Tomcat and the webapps.
Then reading a little further the text seems to be saying "Forget all that stuff". Tomcat does not do it this way....
If I'm reading it right, would it be simpler to just replace the above mentioned text with,
----------------------------------------------------------------
....
System - The standard Tomcat 6 startup scripts ($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat) ignore the contents of the CLASSPATH environment variable (Unlike most java daemons and applications), and instead
build the system classloader from the following repositories:
...
----------------------------------------------------------------
Thoughts?
Thanks,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Class Loader Documentation
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Ole Ersoy" <ol...@gmail.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Tuesday, June 17, 2008 6:57 PM
Subject: Re: Class Loader Documentation
>> I think its because its just hard to explain, but maybe it could be made
>> clearer.
>> I think *ignores* is the wrong word.
>>
>> Especially if someone actually looks at catalina bat and sees this line.
>> set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\bootstrap.jar
>> Doesnt look like that script is ignoring CLASSPATH to me ;)
>>
>> ------------
>> When Tomcat starts up, its internal system classes take *priority* over
>> those in the normal "system" classloader CLASSPATH.
>> This is to prevent "Java DLL hell", making sure that external
>> applications do not see the internal tomcat engine, and making sure that
>> tomcat does not use an external class (eg an xml parser), that may be
>> incompatible with tomcat (Its trying to save your butt).
>> ------------
>>
>
>
> Ah OK - I see what you are saying.
>
> I looked at setclasspath.sh and the first thing is does is clear the users
> CLASSPATH variable. So seems like the Tomcat startup scripts rebuild the
> CLASSPATH variable such that only JARS that are available to it on the
> classpath. So if I were to add more jars to the startup script, those
> would still be visible to Tomcat and all applications.
>
>> --- add your version here --- ;)
> (This is what you're saying I think. When I saw *priority* I started
> thinking "How does it priorize?", and for me it's a little clearer if I
> understand that the CLASSPATH variable is rebuilt from scratch...assuming
> that's corrects...OK Here Goes
>
> <Take 2>
> When Tomcat starts up, the startup script first clears the CLASSPATH
> variable. It then adds a few libraries that Tomcat needs to boot, such as
> bootstrap.jar. These libraries contain additional class loaders that
> Tomcat delegates to when it needs it's system classes (Libraries visible
> to Tomcat only and typically contained in CATALINA_HOME/lib).
>
> Note that if you add additional libraries to the startup script lines that
> initialize the CLASSPATH for Tomcat, these will be visible to Tomcat and
> all running web applications as well.
> </Take 2>
>
> Thoughts?
>
> Thanks,
> - Ole
Now you getting hot ;)
Yes that bootstrap process in TC is making its own classloaders and they can
now do anything they want.
The way the tomcat classloader prioritizes... is they simply dont ask the
"Java" System Classloaders to get the item (like an xml parser), they get
it, from where ever they want to.
So they break the delegation scheme, and even if there is an xml parser in
the system classpath, its ignored.
But they only break the java laws of delegation... ie "dont ask your mama",
when they isolating and protecting us from what may be "out there".
When it comes to java.lang and object and lists and all that other good java
stuff... then they behave as good little classloaders, use delegation and
"ask their mama" for it... so that stuff still comes from the system. So
they dont ignore the whole outside world, they making choices.
ie Try get the class from the webapp first, no, ok lets try the share libs,
no ok lets ask the system (which will look in the classpath and at extended
classes) etc.
The thing to get is that compared to normal java apps, that is backwards.
Normal java apps would go.... ask your mama... all the way to the top and
only if the parents cant do it, will they do it.
Its trying to make TC immune to the outside world, and the other stuff a
user may be dumping onto the machine... but the link is still there, because
all the good java stuff is still inside the big mama ;) the stuff we dont
write, like arrays etc.
They hellish complex things... and it does become difficult to explain in
one paragraph, but hopefully now you see what they trying to say ;)
First they look at your world, then they try the outside world... I think if
they dont find the item they looking for in your world, then they will
"eventually" look at the classpath... and so the classpath only comes into
play, if they cant isolate you.
Interesting hey... TC is a mean machine ;)
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Class Loader Documentation
Posted by Ole Ersoy <ol...@gmail.com>.
> I think its because its just hard to explain, but maybe it could be made
> clearer.
> I think *ignores* is the wrong word.
>
> Especially if someone actually looks at catalina bat and sees this line.
> set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\bootstrap.jar
> Doesnt look like that script is ignoring CLASSPATH to me ;)
>
> ------------
> When Tomcat starts up, its internal system classes take *priority* over
> those in the normal "system" classloader CLASSPATH.
> This is to prevent "Java DLL hell", making sure that external
> applications do not see the internal tomcat engine, and making sure that
> tomcat does not use an external class (eg an xml parser), that may be
> incompatible with tomcat (Its trying to save your butt).
> ------------
>
Ah OK - I see what you are saying.
I looked at setclasspath.sh and the first thing is does is clear the users CLASSPATH variable. So seems like the Tomcat startup scripts rebuild the CLASSPATH variable such that only JARS that are available to it on the classpath. So if I were to add more jars to the startup script, those would still be visible to Tomcat and all applications.
> --- add your version here --- ;)
(This is what you're saying I think. When I saw *priority* I started thinking "How does it priorize?", and for me it's a little clearer if I understand that the CLASSPATH variable is rebuilt from scratch...assuming that's corrects...OK Here Goes
<Take 2>
When Tomcat starts up, the startup script first clears the CLASSPATH variable. It then adds a few libraries that Tomcat needs to boot, such as bootstrap.jar. These libraries contain additional class loaders that Tomcat delegates to when it needs it's system classes (Libraries visible to Tomcat only and typically contained in CATALINA_HOME/lib).
Note that if you add additional libraries to the startup script lines that initialize the CLASSPATH for Tomcat, these will be visible to Tomcat and all running web applications as well.
</Take 2>
Thoughts?
Thanks,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Class Loader Documentation
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Ole Ersoy" <ol...@gmail.com>
To: <us...@tomcat.apache.org>
Sent: Tuesday, June 17, 2008 4:41 AM
Subject: Class Loader Documentation
> Hi,
>
> Reading through the classloader documentation for 6.0 I noticed this:
>
> ...
> However, the standard Tomcat 5 startup scripts ...
>
> It seems like this should be:
>
> the standard Tomcat 6 startup scripts
>
> But I figured I'd check before filing a ticket.
>
> Also it seems like this section could be simplified:
>
> ----------------------------------------------------------------
> 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.
> ----------------------------------------------------------------
>
> So this seems to be saying that "normally" all classes that should be
> visible to both Tomcat and webapps are placed in the CLASSPATH environment
> variable. The second sentence seems to reinforce that placing the
> libraries in the CLASSPATH makes them visible to both Tomcat and the
> webapps.
>
> Then reading a little further the text seems to be saying "Forget all that
> stuff". Tomcat does not do it this way....
>
> If I'm reading it right, would it be simpler to just replace the above
> mentioned text with,
> ----------------------------------------------------------------
> ....
> System - The standard Tomcat 6 startup scripts
> ($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat)
> ignore the contents of the CLASSPATH environment variable (Unlike most
> java daemons and applications), and instead
> build the system classloader from the following repositories:
> ...
> ----------------------------------------------------------------
>
> Thoughts?
>
I think its because its just hard to explain, but maybe it could be made
clearer.
I think *ignores* is the wrong word.
Especially if someone actually looks at catalina bat and sees this line.
set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\bootstrap.jar
Doesnt look like that script is ignoring CLASSPATH to me ;)
------------
When Tomcat starts up, its internal system classes take *priority* over
those in the normal "system" classloader CLASSPATH.
This is to prevent "Java DLL hell", making sure that external applications
do not see the internal tomcat engine, and making sure that tomcat does not
use an external class (eg an xml parser), that may be incompatible with
tomcat (Its trying to save your butt).
------------
--- add your version here --- ;)
Actually look back at TC 5.5... it is getting simpler, believe it or not ;)
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org