Re: Class Loader Documentation
- Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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. Thoughts? Thanks, - Ole - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class Loader Documentation
- Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: "Tomcat Users List" 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 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
