You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jon Stevens <jo...@latchkey.com> on 2000/09/25 22:01:20 UTC
loading of classes in tomcat 3.2b4 is _sloooooow_
Ok,
Using Tomcat 3.1, Turbine starts up _really_ quickly.
Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
Once things have initialized, everything runs very quickly.
Turbine has a boat load of .jar files and doing some initial testing, I
suspect that something in Tomcat changed with regards to class file loading
because if I remove some of the .jar's that I know I'm not using then things
speed up.
Costin, any ideas? This is painful.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: [bug] linking error
Posted by Conny Krappatsch <co...@smb-tec.com>.
Stefano Mazzocchi wrote:
> Here is another pretty serious bug report:
>
> 1) downloaded Tomcat 4.0M1
> 2) latest Cocoon2 from CVS
>
> when executed (Sun JDK 1.3 under Win2k) I get
>
> java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> constraints
> at
> _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> at
> org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> at java.lang.Thread.run(Thread.java:479)
>
> but if I remove xerces.jar from /lib everything works just fine.
Looks like the problem I reported in my previous mail. Removing
xerces.jar worked, too (thanks for this).
My configuration is Tomcat 4.0M1, latest Cocoon2 from CVS, JDK 1.2.2 under
Linux.
--
_____________________________________________________________________
Conny Krappatsch mailto:conny@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: [bug] linking error
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Giacomo Pati wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > "Craig R. McClanahan" wrote:
> > > >
> > > > Stefano Mazzocchi wrote:
> > > >
> > > > > "Craig R. McClanahan" wrote:
> > > > >
> > > > > > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > > > > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > > > > > files. Every user tend to put them into their own JARs
> > > > > > > b) The same classes are not compatible between versions. I can not simply replace
> > > > > > > them with the latest version (by compiling and putting them in a JAR in the
> > > > > > > lib/ext/ directory) which would temporarily solve my problems.
> > > > > > >
> > > > > > > But I guess you are on top of this...
> > > > > >
> > > > > > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > > > > > with everyone else :-).
> > > > >
> > > > > We appear to suffer more consequences of this than planned.
> > > > >
> > > > > Here is another pretty serious bug report:
> > > > >
> > > > > 1) downloaded Tomcat 4.0M1
> > > > > 2) latest Cocoon2 from CVS
> > > > >
> > > > > when executed (Sun JDK 1.3 under Win2k) I get
> > > > >
> > > > > java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> > > > > constraints
> > > > > at
> > > > > _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> > > > > at
> > > > > org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> > > > > at java.lang.Thread.run(Thread.java:479)
> > > > >
> > > > > but if I remove xerces.jar from /lib everything works just fine.
> > > > >
> > > > > NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> > > > > right SAX classes.
> > > > >
> > > > > How about that?
> > > > >
> > > >
> > > > I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
> > > > in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
> > > > different class (org.w3c.dom.Document) instead.
> > > >
> > > > A few comments and questions.
> > > >
> > > > * According to the Javadocs, a LinkageError means that
> > > > a class was changed this class depended on, without
> > > > recompiling this class. Is there any chance at all that the
> > > > xerces.jar (from the 1.2 binary download) was not built from
> > > > scratch (build clean then build dist or whatever)?
> > > >
> > > > * I turned on debugging output in the Catalina class loader.
> > > > It appears that the actual generated sitemap class is being
> > > > started on another thread, using a different classloader. If
> > > > so, what class is being used, and how is it being configured?
> > > > I don't know enough Cocoon internals to track this down.
> > >
> > > Oh, shit you're right... didn't think of this...
> > >
> > > Giacomo, did you use a different classloader for the compiling thread?
> >
> > No, I use the XSP engine to compile and instantiate the sitemap. I
> > thought all the classloading stuff should happen in the ClassUtils class
> > now. But after alook into JavaLanguage I've realized that XSP loads
> > class with class.newInstance() and also something about its own
> > classloader. Could this be a problem?
>
> I thought I unified all classloading thru ClassUtils... is there some
> code that is not using it that way?
Yes. The JavaLanguage class don't loads it with ClassUtils.
> > >
> > > > * Likewise, I don't see anywhere in the code that is writing the
> > > > LinkageError exception message to System.out in the first
> > > > place. Any ideas where this is coming from? (The stack trace
> > > > sent back to the browser is a NullPointerException).
> > >
> > > It's out from the above sitemap compiling thread and the NPE is due to a
> > > bug since the two thread are not well communicating... we need to fix
> > > that soon.
> >
> > Tell me hat the general problem is and I'll fix it (if I'm able to).
>
> Ok, the problem is that if the sitemap cannot be compiled, the exception
> triggered to the browser client is a NPE while the real sitemap
> exception goes to System.out.
>
> I think this is wrong since the compiling thread should (somehow) send
> the exception back to the starting thread (which is reponsible to
> provide the exception that goes to the client)
I thought having done this correctly but some weeks ago you changed the
logic in the exception reporting in sitemap.Handler back to the starting
thread and I haven't given too much attention on what you've changed.
But looking at the code now I don't see where the problem is.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: [bug] linking error
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Stefano Mazzocchi wrote:
> >
> > "Craig R. McClanahan" wrote:
> > >
> > > Stefano Mazzocchi wrote:
> > >
> > > > "Craig R. McClanahan" wrote:
> > > >
> > > > > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > > > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > > > > files. Every user tend to put them into their own JARs
> > > > > > b) The same classes are not compatible between versions. I can not simply replace
> > > > > > them with the latest version (by compiling and putting them in a JAR in the
> > > > > > lib/ext/ directory) which would temporarily solve my problems.
> > > > > >
> > > > > > But I guess you are on top of this...
> > > > >
> > > > > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > > > > with everyone else :-).
> > > >
> > > > We appear to suffer more consequences of this than planned.
> > > >
> > > > Here is another pretty serious bug report:
> > > >
> > > > 1) downloaded Tomcat 4.0M1
> > > > 2) latest Cocoon2 from CVS
> > > >
> > > > when executed (Sun JDK 1.3 under Win2k) I get
> > > >
> > > > java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> > > > constraints
> > > > at
> > > > _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> > > > at
> > > > org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> > > > at java.lang.Thread.run(Thread.java:479)
> > > >
> > > > but if I remove xerces.jar from /lib everything works just fine.
> > > >
> > > > NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> > > > right SAX classes.
> > > >
> > > > How about that?
> > > >
> > >
> > > I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
> > > in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
> > > different class (org.w3c.dom.Document) instead.
> > >
> > > A few comments and questions.
> > >
> > > * According to the Javadocs, a LinkageError means that
> > > a class was changed this class depended on, without
> > > recompiling this class. Is there any chance at all that the
> > > xerces.jar (from the 1.2 binary download) was not built from
> > > scratch (build clean then build dist or whatever)?
> > >
> > > * I turned on debugging output in the Catalina class loader.
> > > It appears that the actual generated sitemap class is being
> > > started on another thread, using a different classloader. If
> > > so, what class is being used, and how is it being configured?
> > > I don't know enough Cocoon internals to track this down.
> >
> > Oh, shit you're right... didn't think of this...
> >
> > Giacomo, did you use a different classloader for the compiling thread?
>
> No, I use the XSP engine to compile and instantiate the sitemap. I
> thought all the classloading stuff should happen in the ClassUtils class
> now. But after alook into JavaLanguage I've realized that XSP loads
> class with class.newInstance() and also something about its own
> classloader. Could this be a problem?
I thought I unified all classloading thru ClassUtils... is there some
code that is not using it that way?
> >
> > > * Likewise, I don't see anywhere in the code that is writing the
> > > LinkageError exception message to System.out in the first
> > > place. Any ideas where this is coming from? (The stack trace
> > > sent back to the browser is a NullPointerException).
> >
> > It's out from the above sitemap compiling thread and the NPE is due to a
> > bug since the two thread are not well communicating... we need to fix
> > that soon.
>
> Tell me hat the general problem is and I'll fix it (if I'm able to).
Ok, the problem is that if the sitemap cannot be compiled, the exception
triggered to the browser client is a NPE while the real sitemap
exception goes to System.out.
I think this is wrong since the compiling thread should (somehow) send
the exception back to the starting thread (which is reponsible to
provide the exception that goes to the client)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [bug] linking error
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> "Craig R. McClanahan" wrote:
> >
> > Stefano Mazzocchi wrote:
> >
> > > "Craig R. McClanahan" wrote:
> > >
> > > > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > > > files. Every user tend to put them into their own JARs
> > > > > b) The same classes are not compatible between versions. I can not simply replace
> > > > > them with the latest version (by compiling and putting them in a JAR in the
> > > > > lib/ext/ directory) which would temporarily solve my problems.
> > > > >
> > > > > But I guess you are on top of this...
> > > >
> > > > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > > > with everyone else :-).
> > >
> > > We appear to suffer more consequences of this than planned.
> > >
> > > Here is another pretty serious bug report:
> > >
> > > 1) downloaded Tomcat 4.0M1
> > > 2) latest Cocoon2 from CVS
> > >
> > > when executed (Sun JDK 1.3 under Win2k) I get
> > >
> > > java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> > > constraints
> > > at
> > > _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> > > at
> > > org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> > > at java.lang.Thread.run(Thread.java:479)
> > >
> > > but if I remove xerces.jar from /lib everything works just fine.
> > >
> > > NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> > > right SAX classes.
> > >
> > > How about that?
> > >
> >
> > I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
> > in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
> > different class (org.w3c.dom.Document) instead.
> >
> > A few comments and questions.
> >
> > * According to the Javadocs, a LinkageError means that
> > a class was changed this class depended on, without
> > recompiling this class. Is there any chance at all that the
> > xerces.jar (from the 1.2 binary download) was not built from
> > scratch (build clean then build dist or whatever)?
> >
> > * I turned on debugging output in the Catalina class loader.
> > It appears that the actual generated sitemap class is being
> > started on another thread, using a different classloader. If
> > so, what class is being used, and how is it being configured?
> > I don't know enough Cocoon internals to track this down.
>
> Oh, shit you're right... didn't think of this...
>
> Giacomo, did you use a different classloader for the compiling thread?
No, I use the XSP engine to compile and instantiate the sitemap. I
thought all the classloading stuff should happen in the ClassUtils class
now. But after alook into JavaLanguage I've realized that XSP loads
class with class.newInstance() and also something about its own
classloader. Could this be a problem?
>
> > * Likewise, I don't see anywhere in the code that is writing the
> > LinkageError exception message to System.out in the first
> > place. Any ideas where this is coming from? (The stack trace
> > sent back to the browser is a NullPointerException).
>
> It's out from the above sitemap compiling thread and the NPE is due to a
> bug since the two thread are not well communicating... we need to fix
> that soon.
Tell me hat the general problem is and I'll fix it (if I'm able to).
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: [bug] linking error
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craig R. McClanahan" wrote:
>
> Stefano Mazzocchi wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > > files. Every user tend to put them into their own JARs
> > > > b) The same classes are not compatible between versions. I can not simply replace
> > > > them with the latest version (by compiling and putting them in a JAR in the
> > > > lib/ext/ directory) which would temporarily solve my problems.
> > > >
> > > > But I guess you are on top of this...
> > >
> > > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > > with everyone else :-).
> >
> > We appear to suffer more consequences of this than planned.
> >
> > Here is another pretty serious bug report:
> >
> > 1) downloaded Tomcat 4.0M1
> > 2) latest Cocoon2 from CVS
> >
> > when executed (Sun JDK 1.3 under Win2k) I get
> >
> > java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> > constraints
> > at
> > _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> > at
> > org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> > at java.lang.Thread.run(Thread.java:479)
> >
> > but if I remove xerces.jar from /lib everything works just fine.
> >
> > NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> > right SAX classes.
> >
> > How about that?
> >
>
> I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
> in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
> different class (org.w3c.dom.Document) instead.
>
> A few comments and questions.
>
> * According to the Javadocs, a LinkageError means that
> a class was changed this class depended on, without
> recompiling this class. Is there any chance at all that the
> xerces.jar (from the 1.2 binary download) was not built from
> scratch (build clean then build dist or whatever)?
>
> * I turned on debugging output in the Catalina class loader.
> It appears that the actual generated sitemap class is being
> started on another thread, using a different classloader. If
> so, what class is being used, and how is it being configured?
> I don't know enough Cocoon internals to track this down.
Oh, shit you're right... didn't think of this...
Giacomo, did you use a different classloader for the compiling thread?
> * Likewise, I don't see anywhere in the code that is writing the
> LinkageError exception message to System.out in the first
> place. Any ideas where this is coming from? (The stack trace
> sent back to the browser is a NullPointerException).
It's out from the above sitemap compiling thread and the NPE is due to a
bug since the two thread are not well communicating... we need to fix
that soon.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [bug] linking error
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craig R. McClanahan" wrote:
>
> Stefano Mazzocchi wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > > files. Every user tend to put them into their own JARs
> > > > b) The same classes are not compatible between versions. I can not simply replace
> > > > them with the latest version (by compiling and putting them in a JAR in the
> > > > lib/ext/ directory) which would temporarily solve my problems.
> > > >
> > > > But I guess you are on top of this...
> > >
> > > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > > with everyone else :-).
> >
> > We appear to suffer more consequences of this than planned.
> >
> > Here is another pretty serious bug report:
> >
> > 1) downloaded Tomcat 4.0M1
> > 2) latest Cocoon2 from CVS
> >
> > when executed (Sun JDK 1.3 under Win2k) I get
> >
> > java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> > constraints
> > at
> > _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> > at
> > org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> > at java.lang.Thread.run(Thread.java:479)
> >
> > but if I remove xerces.jar from /lib everything works just fine.
> >
> > NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> > right SAX classes.
> >
> > How about that?
> >
>
> I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
> in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
> different class (org.w3c.dom.Document) instead.
>
> A few comments and questions.
>
> * According to the Javadocs, a LinkageError means that
> a class was changed this class depended on, without
> recompiling this class. Is there any chance at all that the
> xerces.jar (from the 1.2 binary download) was not built from
> scratch (build clean then build dist or whatever)?
>
> * I turned on debugging output in the Catalina class loader.
> It appears that the actual generated sitemap class is being
> started on another thread, using a different classloader. If
> so, what class is being used, and how is it being configured?
> I don't know enough Cocoon internals to track this down.
Oh, shit you're right... didn't think of this...
Giacomo, did you use a different classloader for the compiling thread?
> * Likewise, I don't see anywhere in the code that is writing the
> LinkageError exception message to System.out in the first
> place. Any ideas where this is coming from? (The stack trace
> sent back to the browser is a NullPointerException).
It's out from the above sitemap compiling thread and the NPE is due to a
bug since the two thread are not well communicating... we need to fix
that soon.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [bug] linking error
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Stefano Mazzocchi wrote:
> "Craig R. McClanahan" wrote:
>
> > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > files. Every user tend to put them into their own JARs
> > > b) The same classes are not compatible between versions. I can not simply replace
> > > them with the latest version (by compiling and putting them in a JAR in the
> > > lib/ext/ directory) which would temporarily solve my problems.
> > >
> > > But I guess you are on top of this...
> >
> > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > with everyone else :-).
>
> We appear to suffer more consequences of this than planned.
>
> Here is another pretty serious bug report:
>
> 1) downloaded Tomcat 4.0M1
> 2) latest Cocoon2 from CVS
>
> when executed (Sun JDK 1.3 under Win2k) I get
>
> java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> constraints
> at
> _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> at
> org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> at java.lang.Thread.run(Thread.java:479)
>
> but if I remove xerces.jar from /lib everything works just fine.
>
> NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> right SAX classes.
>
> How about that?
>
I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
different class (org.w3c.dom.Document) instead.
A few comments and questions.
* According to the Javadocs, a LinkageError means that
a class was changed this class depended on, without
recompiling this class. Is there any chance at all that the
xerces.jar (from the 1.2 binary download) was not built from
scratch (build clean then build dist or whatever)?
* I turned on debugging output in the Catalina class loader.
It appears that the actual generated sitemap class is being
started on another thread, using a different classloader. If
so, what class is being used, and how is it being configured?
I don't know enough Cocoon internals to track this down.
* Likewise, I don't see anywhere in the code that is writing the
LinkageError exception message to System.out in the first
place. Any ideas where this is coming from? (The stack trace
sent back to the browser is a NullPointerException).
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: [bug] linking error
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Stefano Mazzocchi wrote:
> "Craig R. McClanahan" wrote:
>
> > > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > > a) The classes from W3C were never properly packaged and maintained into JAR
> > > files. Every user tend to put them into their own JARs
> > > b) The same classes are not compatible between versions. I can not simply replace
> > > them with the latest version (by compiling and putting them in a JAR in the
> > > lib/ext/ directory) which would temporarily solve my problems.
> > >
> > > But I guess you are on top of this...
> >
> > I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> > with everyone else :-).
>
> We appear to suffer more consequences of this than planned.
>
> Here is another pretty serious bug report:
>
> 1) downloaded Tomcat 4.0M1
> 2) latest Cocoon2 from CVS
>
> when executed (Sun JDK 1.3 under Win2k) I get
>
> java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
> constraints
> at
> _C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
> at
> org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
> at java.lang.Thread.run(Thread.java:479)
>
> but if I remove xerces.jar from /lib everything works just fine.
>
> NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
> right SAX classes.
>
> How about that?
>
I was able to reproduce this, but it fails for me under all three circumstances (xerces.jar in both places, xerces.jar
in $CATALINA_HOME/lib only, and xerces.jar in the Cocoon WEB-INF/lib only). In the latter case, it complained about a
different class (org.w3c.dom.Document) instead.
A few comments and questions.
* According to the Javadocs, a LinkageError means that
a class was changed this class depended on, without
recompiling this class. Is there any chance at all that the
xerces.jar (from the 1.2 binary download) was not built from
scratch (build clean then build dist or whatever)?
* I turned on debugging output in the Catalina class loader.
It appears that the actual generated sitemap class is being
started on another thread, using a different classloader. If
so, what class is being used, and how is it being configured?
I don't know enough Cocoon internals to track this down.
* Likewise, I don't see anywhere in the code that is writing the
LinkageError exception message to System.out in the first
place. Any ideas where this is coming from? (The stack trace
sent back to the browser is a NullPointerException).
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
[bug] linking error
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craig R. McClanahan" wrote:
> > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > a) The classes from W3C were never properly packaged and maintained into JAR
> > files. Every user tend to put them into their own JARs
> > b) The same classes are not compatible between versions. I can not simply replace
> > them with the latest version (by compiling and putting them in a JAR in the
> > lib/ext/ directory) which would temporarily solve my problems.
> >
> > But I guess you are on top of this...
>
> I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> with everyone else :-).
We appear to suffer more consequences of this than planned.
Here is another pretty serious bug report:
1) downloaded Tomcat 4.0M1
2) latest Cocoon2 from CVS
when executed (Sun JDK 1.3 under Win2k) I get
java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
constraints
at
_C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
at
org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
at java.lang.Thread.run(Thread.java:479)
but if I remove xerces.jar from /lib everything works just fine.
NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
right SAX classes.
How about that?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
[bug] linking error
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craig R. McClanahan" wrote:
> > However, I agree that shared libraries are badly defined in the W3C/XML world.
> > a) The classes from W3C were never properly packaged and maintained into JAR
> > files. Every user tend to put them into their own JARs
> > b) The same classes are not compatible between versions. I can not simply replace
> > them with the latest version (by compiling and putting them in a JAR in the
> > lib/ext/ directory) which would temporarily solve my problems.
> >
> > But I guess you are on top of this...
>
> I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
> with everyone else :-).
We appear to suffer more consequences of this than planned.
Here is another pretty serious bug report:
1) downloaded Tomcat 4.0M1
2) latest Cocoon2 from CVS
when executed (Sun JDK 1.3 under Win2k) I get
java.lang.LinkageError: Class org/xml/sax/Attributes violates loader
constraints
at
_C_._Code._apache_org._jakarta_tomcat_4_0_m1._webapps._cocoon._sitemap_xmap.setConfiguration(_sitemap_xmap.java:480)
at
org.apache.cocoon.sitemap.SitemapHandler.run(SitemapHandler.java:149)
at java.lang.Thread.run(Thread.java:479)
but if I remove xerces.jar from /lib everything works just fine.
NOTE: cocoon/WEB-INF/lib *does* include Xerces_1.2.jar along with the
right SAX classes.
How about that?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Niclas Hedhman wrote:
> "Craig R. McClanahan" wrote:
>
> > The current Catalina classloading strategy is to create the following kinds of
> > classloaders at startup time:
> >
> > * The JVM (at least the Sun one) itself sets up the bootstrap
> > class loader with the contents of $JAVA_HOME/jre/lib/ext
> > (the system extensions you have installed) plus its own
> > basic runtime classes.
>
> Not exactly.
> The Bootstrap classloader is only responsible to deliver the
> $JAVA_HOME/jre/lib/rt.jar classes. The JVM will then instantiate a URLClassloader
> for the $JAVA_HOME/jre/lib/ext directory (and directories found in one of the
> system properties (java.lib.ext?), formally called the Extension classloader,
> using the Bootstrap CL as the parent.
> The startup is then creating the System CL with the Extension CL as the parent,
> which points to the classes in the -cp and CLASSPATH settings.
>
True.
Classloaders are rather arcane, and I skipped over a few details.
>
> > * The system class loader is configured to contain the
> > $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> > jars in $CATALINA_HOME/lib. Any CLASSPATH
> > variable that the user currently has set is totally
> > ignored (I'm negotiable on this, but I'm really tired of all
> > the user problems related to class paths). The JAR files
> > here should be the ones required by more than one webapp.
> > The parent of this class loader is the bootstrap class loader.
>
> Is this the standard system CL or a home brew?? If standard, how do you manage to
> kill the CLASSPATH inclusion?
>
It is now based on URLClassLoader, but adds features required to support auto-reload
when class files are changed.
Arg, I see that I typed this wrong ... the parentage tree of a webapp classloader
actually ends up looking like this:
Bootstrap
|
System Extensions
|
System Classloader (bootstrap.jar + $CATALINA_HOME/lib)
|
Webapp Classloader
The parentage tree for the internal Catalina classes are slightly different:
Bootstrap
|
System Extensions
|
System Classloader (bootstrap.jar + $CATALINA_HOME/lib)
|
Catalina Classloader ($CATALINA_HOME/server)
The Catalina classloader is an implementation of the same class used for webapps
(org.apache.catalina.loader.StandardClassLoader) but the set of repositories is
configured dynamically from the $CATALINA_HOME/server directory.
When webapp classloaders are created, the parent classloader is explicitly set to be
the system classloader so that the Catalina classes get bypassed. This is one of the
protections against malicious webapps being able to munge around with Catalina
internals by casting the request and response objects they receive back to the
internal implementation classes.
>
> > * The Catalina class loader contains all of the implementation
> > classes of Catalina itself, and libraries it needs. This is created
> > automatically from the jar files in $CATALINA_HOME/server.
> > These classes are *not* exposed to webapps.
>
> Why would there be a need for a separate "Application" classloader? That would
> typically be the purpose of the System CL. Or is it that the "Catalina CL" uses
> the Extension CL as the parent, bypassing the normal System CL, and provides the
> same functionality, and thereby easily bypasses the CLASSPATH settings? But the
> statement below indicates that this CL is a sibling of the WebApp CLs.
>
Each webapp has access to a unique set of classes -- the ones in WEB-INF/classes/ and
WEB-INF/lib/*.jars. Therefore they need separate classloaders.
The webapp CLs are siblings of each other, but the parent CL in each case is the
System CL, not the Catalina one -- because they are created with an explicit parent.
>
> > * The webapp class loader (one per webapp) is configured from
> > the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> > webapp. It's parent class loader is the system class loader
> > (see above).
>
> > One of the big issues with any sort of "shared library" approach is, what do
> > you do when the same class appears in both the webapp class loader and the
> > system class loader? Which one wins?
> >
> > In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
> > Java2 delegation model, and always goes to the parent first (i.e. the system
> > classpath), and then in the webapp. If you've got the same class both places
> > (like an XML parser or a JDBC driver), the one on the system classpath wins.
> > By the way, this is what caused so much grief in Tomcat 3.1 with people trying
> > to run their own parsers that had some classes in common with the "xml.jar"
> > parser shipped with 3.1.
> >
> > In Tomcat 4.0, Catalina by default follows the new search order articulated as
> > a "recommendation" in the servlet 2.3 draft spec:
> > * WEB-INF/classes
> > * WEB-INF/lib/*.jar
> > * System class loader
> > so that a library found in the webapp will always win. This can be configured
> > out (although not very gracefully at the moment), but seems to meet the
> > majority of use cases better than the previous scheme.
>
> This sounds like a security hole... I can not pinpoint a possible attack, but one
> of the reasons for the Java2 model was security.
>
There are multiple levels to the issue of security. Let's look at a couple of them:
* Who can install webapps in your server in the first place? Normally, this is done
by a system administrator who makes some sort of "trust" decision.
* What bad things can a webapp do (let's assume it's a third party closed source
product that you cannot examine)? If the webapp has write access to
WEB-INF/classes
or WEB-INF/lib, it can pretty easily import new classes (say, from the network)
and install them. That's why you would normally want to run a security-sensitive
app under a Java security manager as well (not yet supported by Tomcat 4.0, but
it will be) to prevent such things.
* Can a webapp mess around with internal server objects? No -- not only is the
Catalina CL skipped when setting up the webapp CL, the webapp CLs are also
configured to refuse any attempt to load a class named "org.apache.catalina.*",
and to delegate upwards unconditionally for any class that starts "java.*" or
"javax.servlet.*". So, a webapp cannot impersonate a system class either.
All of the security related stuff is going to be summarized into a document that
contains assertions about what Catalina does and does not allow, with pointers to the
implementation of the various protections. Given that, we will be able to audit the
robustness of the security features in place and fix any flaws that are found.
>
> > > > So the first question would be : when an application share common library
> > > > (say DOM and sax packages), what are the benefits of delivering the war
> > > > Webapp file with the web-inf/lib conataining the duplicated library (for
> > > > cocoon the shared libraries are Xerces (since catalina can works with
> > > > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
> > >
> > > The first and basic advantage is ease of installation. Drag your war
> > > file and you're done.
> > >
> > > The second advantage is complete separation: no problem with class cast
> > > exceptions and all that since the web-inf/lib takes precedence (I like
> > > this very much)
> > >
> >
> > The third advantage is that some libraries will not work correctly unless they
> > are installed in the webapp. I believe Cocoon has run into this -- I'll
> > describe what I ran into with Struts because it's similar.
> >
> > Struts includes a module called Digester (very similar to the XmlMapper that is
> > used inside Tomcat to configure itself from the server.xml and web.xml files).
> > One of the things you can do is create a new object when a particular XML
> > element is encountered. But, if the digester classes are loaded from the
> > system class path, and the Java class of the object you're trying to create is
> > in the webapp (a very typical case), you're out of luck --
> > ClassNotFoundException because the Digester tries to use the classloader it was
> > itself loaded from (i.e. system class loader).
>
> That is because of inappropriate use of dynamic classloading. The procedure is to
> properly set up the thread's context classloader, and all dynamic classloading
> should use Thread.currentThread().getContextClassloader().loadClass() to get
> around this problem.
>
This works only in Java2 -- JDK 1.1 does not have the concept of a context class
loader, so you cannot use it if your app has to remain compatible with 1.1.
>
> However, I agree that shared libraries are badly defined in the W3C/XML world.
> a) The classes from W3C were never properly packaged and maintained into JAR
> files. Every user tend to put them into their own JARs
> b) The same classes are not compatible between versions. I can not simply replace
> them with the latest version (by compiling and putting them in a JAR in the
> lib/ext/ directory) which would temporarily solve my problems.
>
> But I guess you are on top of this...
I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
with everyone else :-).
>
> Niclas
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Niclas Hedhman wrote:
> "Craig R. McClanahan" wrote:
>
> > The current Catalina classloading strategy is to create the following kinds of
> > classloaders at startup time:
> >
> > * The JVM (at least the Sun one) itself sets up the bootstrap
> > class loader with the contents of $JAVA_HOME/jre/lib/ext
> > (the system extensions you have installed) plus its own
> > basic runtime classes.
>
> Not exactly.
> The Bootstrap classloader is only responsible to deliver the
> $JAVA_HOME/jre/lib/rt.jar classes. The JVM will then instantiate a URLClassloader
> for the $JAVA_HOME/jre/lib/ext directory (and directories found in one of the
> system properties (java.lib.ext?), formally called the Extension classloader,
> using the Bootstrap CL as the parent.
> The startup is then creating the System CL with the Extension CL as the parent,
> which points to the classes in the -cp and CLASSPATH settings.
>
True.
Classloaders are rather arcane, and I skipped over a few details.
>
> > * The system class loader is configured to contain the
> > $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> > jars in $CATALINA_HOME/lib. Any CLASSPATH
> > variable that the user currently has set is totally
> > ignored (I'm negotiable on this, but I'm really tired of all
> > the user problems related to class paths). The JAR files
> > here should be the ones required by more than one webapp.
> > The parent of this class loader is the bootstrap class loader.
>
> Is this the standard system CL or a home brew?? If standard, how do you manage to
> kill the CLASSPATH inclusion?
>
It is now based on URLClassLoader, but adds features required to support auto-reload
when class files are changed.
Arg, I see that I typed this wrong ... the parentage tree of a webapp classloader
actually ends up looking like this:
Bootstrap
|
System Extensions
|
System Classloader (bootstrap.jar + $CATALINA_HOME/lib)
|
Webapp Classloader
The parentage tree for the internal Catalina classes are slightly different:
Bootstrap
|
System Extensions
|
System Classloader (bootstrap.jar + $CATALINA_HOME/lib)
|
Catalina Classloader ($CATALINA_HOME/server)
The Catalina classloader is an implementation of the same class used for webapps
(org.apache.catalina.loader.StandardClassLoader) but the set of repositories is
configured dynamically from the $CATALINA_HOME/server directory.
When webapp classloaders are created, the parent classloader is explicitly set to be
the system classloader so that the Catalina classes get bypassed. This is one of the
protections against malicious webapps being able to munge around with Catalina
internals by casting the request and response objects they receive back to the
internal implementation classes.
>
> > * The Catalina class loader contains all of the implementation
> > classes of Catalina itself, and libraries it needs. This is created
> > automatically from the jar files in $CATALINA_HOME/server.
> > These classes are *not* exposed to webapps.
>
> Why would there be a need for a separate "Application" classloader? That would
> typically be the purpose of the System CL. Or is it that the "Catalina CL" uses
> the Extension CL as the parent, bypassing the normal System CL, and provides the
> same functionality, and thereby easily bypasses the CLASSPATH settings? But the
> statement below indicates that this CL is a sibling of the WebApp CLs.
>
Each webapp has access to a unique set of classes -- the ones in WEB-INF/classes/ and
WEB-INF/lib/*.jars. Therefore they need separate classloaders.
The webapp CLs are siblings of each other, but the parent CL in each case is the
System CL, not the Catalina one -- because they are created with an explicit parent.
>
> > * The webapp class loader (one per webapp) is configured from
> > the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> > webapp. It's parent class loader is the system class loader
> > (see above).
>
> > One of the big issues with any sort of "shared library" approach is, what do
> > you do when the same class appears in both the webapp class loader and the
> > system class loader? Which one wins?
> >
> > In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
> > Java2 delegation model, and always goes to the parent first (i.e. the system
> > classpath), and then in the webapp. If you've got the same class both places
> > (like an XML parser or a JDBC driver), the one on the system classpath wins.
> > By the way, this is what caused so much grief in Tomcat 3.1 with people trying
> > to run their own parsers that had some classes in common with the "xml.jar"
> > parser shipped with 3.1.
> >
> > In Tomcat 4.0, Catalina by default follows the new search order articulated as
> > a "recommendation" in the servlet 2.3 draft spec:
> > * WEB-INF/classes
> > * WEB-INF/lib/*.jar
> > * System class loader
> > so that a library found in the webapp will always win. This can be configured
> > out (although not very gracefully at the moment), but seems to meet the
> > majority of use cases better than the previous scheme.
>
> This sounds like a security hole... I can not pinpoint a possible attack, but one
> of the reasons for the Java2 model was security.
>
There are multiple levels to the issue of security. Let's look at a couple of them:
* Who can install webapps in your server in the first place? Normally, this is done
by a system administrator who makes some sort of "trust" decision.
* What bad things can a webapp do (let's assume it's a third party closed source
product that you cannot examine)? If the webapp has write access to
WEB-INF/classes
or WEB-INF/lib, it can pretty easily import new classes (say, from the network)
and install them. That's why you would normally want to run a security-sensitive
app under a Java security manager as well (not yet supported by Tomcat 4.0, but
it will be) to prevent such things.
* Can a webapp mess around with internal server objects? No -- not only is the
Catalina CL skipped when setting up the webapp CL, the webapp CLs are also
configured to refuse any attempt to load a class named "org.apache.catalina.*",
and to delegate upwards unconditionally for any class that starts "java.*" or
"javax.servlet.*". So, a webapp cannot impersonate a system class either.
All of the security related stuff is going to be summarized into a document that
contains assertions about what Catalina does and does not allow, with pointers to the
implementation of the various protections. Given that, we will be able to audit the
robustness of the security features in place and fix any flaws that are found.
>
> > > > So the first question would be : when an application share common library
> > > > (say DOM and sax packages), what are the benefits of delivering the war
> > > > Webapp file with the web-inf/lib conataining the duplicated library (for
> > > > cocoon the shared libraries are Xerces (since catalina can works with
> > > > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
> > >
> > > The first and basic advantage is ease of installation. Drag your war
> > > file and you're done.
> > >
> > > The second advantage is complete separation: no problem with class cast
> > > exceptions and all that since the web-inf/lib takes precedence (I like
> > > this very much)
> > >
> >
> > The third advantage is that some libraries will not work correctly unless they
> > are installed in the webapp. I believe Cocoon has run into this -- I'll
> > describe what I ran into with Struts because it's similar.
> >
> > Struts includes a module called Digester (very similar to the XmlMapper that is
> > used inside Tomcat to configure itself from the server.xml and web.xml files).
> > One of the things you can do is create a new object when a particular XML
> > element is encountered. But, if the digester classes are loaded from the
> > system class path, and the Java class of the object you're trying to create is
> > in the webapp (a very typical case), you're out of luck --
> > ClassNotFoundException because the Digester tries to use the classloader it was
> > itself loaded from (i.e. system class loader).
>
> That is because of inappropriate use of dynamic classloading. The procedure is to
> properly set up the thread's context classloader, and all dynamic classloading
> should use Thread.currentThread().getContextClassloader().loadClass() to get
> around this problem.
>
This works only in Java2 -- JDK 1.1 does not have the concept of a context class
loader, so you cannot use it if your app has to remain compatible with 1.1.
>
> However, I agree that shared libraries are badly defined in the W3C/XML world.
> a) The classes from W3C were never properly packaged and maintained into JAR
> files. Every user tend to put them into their own JARs
> b) The same classes are not compatible between versions. I can not simply replace
> them with the latest version (by compiling and putting them in a JAR in the
> lib/ext/ directory) which would temporarily solve my problems.
>
> But I guess you are on top of this...
I wouldn't say necessarily "on top of" -- more "suffering the consequences of" along
with everyone else :-).
>
> Niclas
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Niclas Hedhman <ni...@bali.ac>.
"Craig R. McClanahan" wrote:
> The current Catalina classloading strategy is to create the following kinds of
> classloaders at startup time:
>
> * The JVM (at least the Sun one) itself sets up the bootstrap
> class loader with the contents of $JAVA_HOME/jre/lib/ext
> (the system extensions you have installed) plus its own
> basic runtime classes.
Not exactly.
The Bootstrap classloader is only responsible to deliver the
$JAVA_HOME/jre/lib/rt.jar classes. The JVM will then instantiate a URLClassloader
for the $JAVA_HOME/jre/lib/ext directory (and directories found in one of the
system properties (java.lib.ext?), formally called the Extension classloader,
using the Bootstrap CL as the parent.
The startup is then creating the System CL with the Extension CL as the parent,
which points to the classes in the -cp and CLASSPATH settings.
> * The system class loader is configured to contain the
> $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> jars in $CATALINA_HOME/lib. Any CLASSPATH
> variable that the user currently has set is totally
> ignored (I'm negotiable on this, but I'm really tired of all
> the user problems related to class paths). The JAR files
> here should be the ones required by more than one webapp.
> The parent of this class loader is the bootstrap class loader.
Is this the standard system CL or a home brew?? If standard, how do you manage to
kill the CLASSPATH inclusion?
> * The Catalina class loader contains all of the implementation
> classes of Catalina itself, and libraries it needs. This is created
> automatically from the jar files in $CATALINA_HOME/server.
> These classes are *not* exposed to webapps.
Why would there be a need for a separate "Application" classloader? That would
typically be the purpose of the System CL. Or is it that the "Catalina CL" uses
the Extension CL as the parent, bypassing the normal System CL, and provides the
same functionality, and thereby easily bypasses the CLASSPATH settings? But the
statement below indicates that this CL is a sibling of the WebApp CLs.
> * The webapp class loader (one per webapp) is configured from
> the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> webapp. It's parent class loader is the system class loader
> (see above).
> One of the big issues with any sort of "shared library" approach is, what do
> you do when the same class appears in both the webapp class loader and the
> system class loader? Which one wins?
>
> In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
> Java2 delegation model, and always goes to the parent first (i.e. the system
> classpath), and then in the webapp. If you've got the same class both places
> (like an XML parser or a JDBC driver), the one on the system classpath wins.
> By the way, this is what caused so much grief in Tomcat 3.1 with people trying
> to run their own parsers that had some classes in common with the "xml.jar"
> parser shipped with 3.1.
>
> In Tomcat 4.0, Catalina by default follows the new search order articulated as
> a "recommendation" in the servlet 2.3 draft spec:
> * WEB-INF/classes
> * WEB-INF/lib/*.jar
> * System class loader
> so that a library found in the webapp will always win. This can be configured
> out (although not very gracefully at the moment), but seems to meet the
> majority of use cases better than the previous scheme.
This sounds like a security hole... I can not pinpoint a possible attack, but one
of the reasons for the Java2 model was security.
> > > So the first question would be : when an application share common library
> > > (say DOM and sax packages), what are the benefits of delivering the war
> > > Webapp file with the web-inf/lib conataining the duplicated library (for
> > > cocoon the shared libraries are Xerces (since catalina can works with
> > > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
> >
> > The first and basic advantage is ease of installation. Drag your war
> > file and you're done.
> >
> > The second advantage is complete separation: no problem with class cast
> > exceptions and all that since the web-inf/lib takes precedence (I like
> > this very much)
> >
>
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it was
> itself loaded from (i.e. system class loader).
That is because of inappropriate use of dynamic classloading. The procedure is to
properly set up the thread's context classloader, and all dynamic classloading
should use Thread.currentThread().getContextClassloader().loadClass() to get
around this problem.
However, I agree that shared libraries are badly defined in the W3C/XML world.
a) The classes from W3C were never properly packaged and maintained into JAR
files. Every user tend to put them into their own JARs
b) The same classes are not compatible between versions. I can not simply replace
them with the latest version (by compiling and putting them in a JAR in the
lib/ext/ directory) which would temporarily solve my problems.
But I guess you are on top of this...
Niclas
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Niclas Hedhman <ni...@bali.ac>.
"Craig R. McClanahan" wrote:
> The current Catalina classloading strategy is to create the following kinds of
> classloaders at startup time:
>
> * The JVM (at least the Sun one) itself sets up the bootstrap
> class loader with the contents of $JAVA_HOME/jre/lib/ext
> (the system extensions you have installed) plus its own
> basic runtime classes.
Not exactly.
The Bootstrap classloader is only responsible to deliver the
$JAVA_HOME/jre/lib/rt.jar classes. The JVM will then instantiate a URLClassloader
for the $JAVA_HOME/jre/lib/ext directory (and directories found in one of the
system properties (java.lib.ext?), formally called the Extension classloader,
using the Bootstrap CL as the parent.
The startup is then creating the System CL with the Extension CL as the parent,
which points to the classes in the -cp and CLASSPATH settings.
> * The system class loader is configured to contain the
> $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> jars in $CATALINA_HOME/lib. Any CLASSPATH
> variable that the user currently has set is totally
> ignored (I'm negotiable on this, but I'm really tired of all
> the user problems related to class paths). The JAR files
> here should be the ones required by more than one webapp.
> The parent of this class loader is the bootstrap class loader.
Is this the standard system CL or a home brew?? If standard, how do you manage to
kill the CLASSPATH inclusion?
> * The Catalina class loader contains all of the implementation
> classes of Catalina itself, and libraries it needs. This is created
> automatically from the jar files in $CATALINA_HOME/server.
> These classes are *not* exposed to webapps.
Why would there be a need for a separate "Application" classloader? That would
typically be the purpose of the System CL. Or is it that the "Catalina CL" uses
the Extension CL as the parent, bypassing the normal System CL, and provides the
same functionality, and thereby easily bypasses the CLASSPATH settings? But the
statement below indicates that this CL is a sibling of the WebApp CLs.
> * The webapp class loader (one per webapp) is configured from
> the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> webapp. It's parent class loader is the system class loader
> (see above).
> One of the big issues with any sort of "shared library" approach is, what do
> you do when the same class appears in both the webapp class loader and the
> system class loader? Which one wins?
>
> In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
> Java2 delegation model, and always goes to the parent first (i.e. the system
> classpath), and then in the webapp. If you've got the same class both places
> (like an XML parser or a JDBC driver), the one on the system classpath wins.
> By the way, this is what caused so much grief in Tomcat 3.1 with people trying
> to run their own parsers that had some classes in common with the "xml.jar"
> parser shipped with 3.1.
>
> In Tomcat 4.0, Catalina by default follows the new search order articulated as
> a "recommendation" in the servlet 2.3 draft spec:
> * WEB-INF/classes
> * WEB-INF/lib/*.jar
> * System class loader
> so that a library found in the webapp will always win. This can be configured
> out (although not very gracefully at the moment), but seems to meet the
> majority of use cases better than the previous scheme.
This sounds like a security hole... I can not pinpoint a possible attack, but one
of the reasons for the Java2 model was security.
> > > So the first question would be : when an application share common library
> > > (say DOM and sax packages), what are the benefits of delivering the war
> > > Webapp file with the web-inf/lib conataining the duplicated library (for
> > > cocoon the shared libraries are Xerces (since catalina can works with
> > > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
> >
> > The first and basic advantage is ease of installation. Drag your war
> > file and you're done.
> >
> > The second advantage is complete separation: no problem with class cast
> > exceptions and all that since the web-inf/lib takes precedence (I like
> > this very much)
> >
>
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it was
> itself loaded from (i.e. system class loader).
That is because of inappropriate use of dynamic classloading. The procedure is to
properly set up the thread's context classloader, and all dynamic classloading
should use Thread.currentThread().getContextClassloader().loadClass() to get
around this problem.
However, I agree that shared libraries are badly defined in the W3C/XML world.
a) The classes from W3C were never properly packaged and maintained into JAR
files. Every user tend to put them into their own JARs
b) The same classes are not compatible between versions. I can not simply replace
them with the latest version (by compiling and putting them in a JAR in the
lib/ext/ directory) which would temporarily solve my problems.
But I guess you are on top of this...
Niclas
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/25/2000 5:49 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> But I can see how that would be a pain during development when you're
> restarting a webapp all the time.
Right...it sucks balls. :-)
> As it happens, over the weekend I installed a new class loader implementation
> that extends the standard Java2 URLClassLoader instead of the home grown
> version. This version is also in the "milestone 1" release. Could you guys
> please try it again with the new one?
Ok, I will try it...if it solves the problems, I will immediately switch the
TDK to use Tomcat 4.0 instead of 3.2b4...
> NOTE: This classloader currently implements auto-reload for classes in
> WEB-INF/classes -- not for classes inside JAR files in WEB-INF/lib. This will
> be fixed later, but should not normally be a problem in a development
> environment, since most people won't waste the time to continually create JAR
> files as they are modifying classes.
Actually, I would be more than happy to leave things as is. That is fine by
me. What I do is remove turbine.jar and then compile Turbine into my
WEB-INF/classes directory.
> Webapp class loaders is one of the issues that was discussed quite a bit for
> servlet 2.3. It's worth reviewing a little background info to bring people up
> to date.
>
> The current Catalina classloading strategy is to create the following kinds of
> classloaders at startup time:
>
> * The JVM (at least the Sun one) itself sets up the bootstrap
> class loader with the contents of $JAVA_HOME/jre/lib/ext
> (the system extensions you have installed) plus its own
> basic runtime classes.
>
> * The system class loader is configured to contain the
> $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> jars in $CATALINA_HOME/lib. Any CLASSPATH
> variable that the user currently has set is totally
> ignored (I'm negotiable on this, but I'm really tired of all
> the user problems related to class paths). The JAR files
> here should be the ones required by more than one webapp.
> The parent of this class loader is the bootstrap class loader.
+1
> * The Catalina class loader contains all of the implementation
> classes of Catalina itself, and libraries it needs. This is created
> automatically from the jar files in $CATALINA_HOME/server.
> These classes are *not* exposed to webapps.
>
> * The webapp class loader (one per webapp) is configured from
> the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> webapp. It's parent class loader is the system class loader
> (see above).
+1
> One of the big issues with any sort of "shared library" approach is, what do
> you do when the same class appears in both the webapp class loader and the
> system class loader? Which one wins?
webapp
> In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
> Java2 delegation model, and always goes to the parent first (i.e. the system
> classpath), and then in the webapp. If you've got the same class both places
> (like an XML parser or a JDBC driver), the one on the system classpath wins.
> By the way, this is what caused so much grief in Tomcat 3.1 with people trying
> to run their own parsers that had some classes in common with the "xml.jar"
> parser shipped with 3.1.
>
> In Tomcat 4.0, Catalina by default follows the new search order articulated as
> a "recommendation" in the servlet 2.3 draft spec:
> * WEB-INF/classes
> * WEB-INF/lib/*.jar
> * System class loader
> so that a library found in the webapp will always win. This can be configured
> out (although not very gracefully at the moment), but seems to meet the
> majority of use cases better than the previous scheme.
+1
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the XmlMapper that
> is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it
> was
> itself loaded from (i.e. system class loader).
:-) Class.forName() woo hoo!
> So, even though reducing the memory footprint (by sharing libraries) is very
> appealing, it is not always going to be practical.
Right...I still want to shoot the person who invented classloaders. :-) It
was fine for JDK 1.0, but should have been re-thought out in 1.1 and totally
re-implemented and deprecated in 1.2/1.3.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
RE: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by James Cook <ji...@iname.com>.
I really like the class loading in Catalina.
The Inprise Application Server also implements a flexible class loading
architecture, and they have a feature that may help users of Tomcat. They
allow the server administrators to determine flexible class loading like you
have now, but they also allow the class loaders to be optionally "combined".
In effect, they can be collapsed down so that there is only one class loader
present for the server and all applications.
Of course this is not the default, but it does give the admins a great deal
of flexibility. I could imagine that Tomcat could go as far as allowing
users to specify a classloader scheme per context in the server.xml file.
The entry could even include a logical classpath that the classloader would
use.
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Monday, September 25, 2000 8:50 PM
> To: tomcat-dev@jakarta.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
>
>
> See below.
>
> Stefano Mazzocchi wrote:
>
> > Sebastien Sahuc wrote:
> > >
> > > I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
> > > annoyance.
> > >
> > > "Craig R. McClanahan" wrote :
> > >
> > > > Sebastien Sahuc wrote:
> > >
> > > > > Same with Catalina .... :-(
> > >
> > > > >
> > > > > Any hint on why is it so slow to start the Catalina ?
> > > > >
> > >
> > > > I don't remember if 3.2 does this, but Catalina logs when
> it starts and
> > > > stops
> > > > initializing the random number generator. It would be
> interesting to
> > > > find
> > > > out if that is the issue or not for you. By the way, this
> is done once
> > > > per
> > > > webapp (they use independent RNGs) so the number of
> different webapps
> > > > you
> > > > have defined matters.
> > >
> > > I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
> > > file, and the more a remove -unecessary- jar files from web-inf, the
> > > faster is the application startup and smoother is the whole running.
> > > I also noticed that having only one Xerces parser (in system
> classpath)
> > > for both cocoon2 webapp and catalina improves notably the average
> > > performance and memory footprint...
> > > I don't have exact figures but we should start now to be
> aware of these
> > > libraries sharing and Classloader issues.
> >
> > Oh, yes. Catalina's classloader is much slower compared to the system
> > classpath. This is pretty obvious... but this is only at boot time, it
> > doesn't make a real difference after you've loaded all the necessary
> > classes.
> >
>
> But I can see how that would be a pain during development when you're
> restarting a webapp all the time.
>
> As it happens, over the weekend I installed a new class loader
> implementation
> that extends the standard Java2 URLClassLoader instead of the home grown
> version. This version is also in the "milestone 1" release.
> Could you guys
> please try it again with the new one?
>
> NOTE: This classloader currently implements auto-reload for classes in
> WEB-INF/classes -- not for classes inside JAR files in
> WEB-INF/lib. This will
> be fixed later, but should not normally be a problem in a development
> environment, since most people won't waste the time to
> continually create JAR
> files as they are modifying classes.
>
> > As for memory footprint, this is pretty obvious, but it could lead to
> > potential security problems.
> >
> > Craig, shouldn't we have a "safe" mode and a "normal" mode for
> > classloading?
> >
>
> Webapp class loaders is one of the issues that was discussed
> quite a bit for
> servlet 2.3. It's worth reviewing a little background info to
> bring people up
> to date.
>
> The current Catalina classloading strategy is to create the
> following kinds of
> classloaders at startup time:
>
> * The JVM (at least the Sun one) itself sets up the bootstrap
> class loader with the contents of $JAVA_HOME/jre/lib/ext
> (the system extensions you have installed) plus its own
> basic runtime classes.
>
> * The system class loader is configured to contain the
> $CATALINA_HOME/bin/bootstrap.jar file, plus all the
> jars in $CATALINA_HOME/lib. Any CLASSPATH
> variable that the user currently has set is totally
> ignored (I'm negotiable on this, but I'm really tired of all
> the user problems related to class paths). The JAR files
> here should be the ones required by more than one webapp.
> The parent of this class loader is the bootstrap class loader.
>
> * The Catalina class loader contains all of the implementation
> classes of Catalina itself, and libraries it needs. This is created
> automatically from the jar files in $CATALINA_HOME/server.
> These classes are *not* exposed to webapps.
>
> * The webapp class loader (one per webapp) is configured from
> the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
> webapp. It's parent class loader is the system class loader
> (see above).
>
> One of the big issues with any sort of "shared library" approach
> is, what do
> you do when the same class appears in both the webapp class loader and the
> system class loader? Which one wins?
>
> In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows
> the standard
> Java2 delegation model, and always goes to the parent first (i.e.
> the system
> classpath), and then in the webapp. If you've got the same class
> both places
> (like an XML parser or a JDBC driver), the one on the system
> classpath wins.
> By the way, this is what caused so much grief in Tomcat 3.1 with
> people trying
> to run their own parsers that had some classes in common with the
> "xml.jar"
> parser shipped with 3.1.
>
> In Tomcat 4.0, Catalina by default follows the new search order
> articulated as
> a "recommendation" in the servlet 2.3 draft spec:
> * WEB-INF/classes
> * WEB-INF/lib/*.jar
> * System class loader
> so that a library found in the webapp will always win. This can
> be configured
> out (although not very gracefully at the moment), but seems to meet the
> majority of use cases better than the previous scheme.
>
> >
> > > So the first question would be : when an application share
> common library
> > > (say DOM and sax packages), what are the benefits of
> delivering the war
> > > Webapp file with the web-inf/lib conataining the duplicated
> library (for
> > > cocoon the shared libraries are Xerces (since catalina can works with
> > > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
> >
> > The first and basic advantage is ease of installation. Drag your war
> > file and you're done.
> >
> > The second advantage is complete separation: no problem with class cast
> > exceptions and all that since the web-inf/lib takes precedence (I like
> > this very much)
> >
>
> The third advantage is that some libraries will not work
> correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the
> XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and
> web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying
> to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the
> classloader it was
> itself loaded from (i.e. system class loader).
>
> So, even though reducing the memory footprint (by sharing
> libraries) is very
> appealing, it is not always going to be practical.
>
>
> >
> > --
> > Stefano Mazzocchi One must still have chaos in oneself to be
> > able to give birth to a dancing star.
> > <st...@apache.org> Friedrich Nietzsche
> > --------------------------------------------------------------------
> > Missed us in Orlando? Make it up with ApacheCON Europe in London!
> > ------------------------- http://ApacheCon.Com ---------------------
> >
>
> Craig
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Aaron Mulder wrote:
> On Mon, 25 Sep 2000, Craig R. McClanahan wrote:
> > The third advantage is that some libraries will not work correctly unless they
> > are installed in the webapp. I believe Cocoon has run into this -- I'll
> > describe what I ran into with Struts because it's similar.
> >
> > Struts includes a module called Digester (very similar to the XmlMapper that is
> > used inside Tomcat to configure itself from the server.xml and web.xml files).
> > One of the things you can do is create a new object when a particular XML
> > element is encountered. But, if the digester classes are loaded from the
> > system class path, and the Java class of the object you're trying to create is
> > in the webapp (a very typical case), you're out of luck --
> > ClassNotFoundException because the Digester tries to use the classloader it was
> > itself loaded from (i.e. system class loader).
>
> This can be solved by judicious use of the
> Thread.contextClassLoader under 1.2. Of course, the library has to
> support that, but Tomcat should already: under 3.2 at least there's the
> Jdk12Interceptor that would set the contextClassLoader for all calls - I
> assume 4.0 has something similar.
>
Tomcat 4.0 has the luxury of assuming a Java2 platform (courtesy of the servlet
2.3/JSP 1.2 specs saying so), so it doesn't need to be in an optional interceptor.
Yes, Tomcat 4.0 sets the context class loader (to the webapp's classloader) as soon
as it knows what context will handle this request.
And yes, it allows properly programmed libraries to work correctly, even if they are
installed on the shared class path, as long as they also assume a Java2 base platform
(context class loader was added in JDK 1.2).
>
> Aaron
>
Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Aaron Mulder wrote:
> On Mon, 25 Sep 2000, Craig R. McClanahan wrote:
> > The third advantage is that some libraries will not work correctly unless they
> > are installed in the webapp. I believe Cocoon has run into this -- I'll
> > describe what I ran into with Struts because it's similar.
> >
> > Struts includes a module called Digester (very similar to the XmlMapper that is
> > used inside Tomcat to configure itself from the server.xml and web.xml files).
> > One of the things you can do is create a new object when a particular XML
> > element is encountered. But, if the digester classes are loaded from the
> > system class path, and the Java class of the object you're trying to create is
> > in the webapp (a very typical case), you're out of luck --
> > ClassNotFoundException because the Digester tries to use the classloader it was
> > itself loaded from (i.e. system class loader).
>
> This can be solved by judicious use of the
> Thread.contextClassLoader under 1.2. Of course, the library has to
> support that, but Tomcat should already: under 3.2 at least there's the
> Jdk12Interceptor that would set the contextClassLoader for all calls - I
> assume 4.0 has something similar.
>
Tomcat 4.0 has the luxury of assuming a Java2 platform (courtesy of the servlet
2.3/JSP 1.2 specs saying so), so it doesn't need to be in an optional interceptor.
Yes, Tomcat 4.0 sets the context class loader (to the webapp's classloader) as soon
as it knows what context will handle this request.
And yes, it allows properly programmed libraries to work correctly, even if they are
installed on the shared class path, as long as they also assume a Java2 base platform
(context class loader was added in JDK 1.2).
>
> Aaron
>
Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 25 Sep 2000, Craig R. McClanahan wrote:
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it was
> itself loaded from (i.e. system class loader).
This can be solved by judicious use of the
Thread.contextClassLoader under 1.2. Of course, the library has to
support that, but Tomcat should already: under 3.2 at least there's the
Jdk12Interceptor that would set the contextClassLoader for all calls - I
assume 4.0 has something similar.
Aaron
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 25 Sep 2000, Craig R. McClanahan wrote:
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp. I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
>
> Struts includes a module called Digester (very similar to the XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered. But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it was
> itself loaded from (i.e. system class loader).
This can be solved by judicious use of the
Thread.contextClassLoader under 1.2. Of course, the library has to
support that, but Tomcat should already: under 3.2 at least there's the
Jdk12Interceptor that would set the contextClassLoader for all calls - I
assume 4.0 has something similar.
Aaron
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
See below.
Stefano Mazzocchi wrote:
> Sebastien Sahuc wrote:
> >
> > I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
> > annoyance.
> >
> > "Craig R. McClanahan" wrote :
> >
> > > Sebastien Sahuc wrote:
> >
> > > > Same with Catalina .... :-(
> >
> > > >
> > > > Any hint on why is it so slow to start the Catalina ?
> > > >
> >
> > > I don't remember if 3.2 does this, but Catalina logs when it starts and
> > > stops
> > > initializing the random number generator. It would be interesting to
> > > find
> > > out if that is the issue or not for you. By the way, this is done once
> > > per
> > > webapp (they use independent RNGs) so the number of different webapps
> > > you
> > > have defined matters.
> >
> > I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
> > file, and the more a remove -unecessary- jar files from web-inf, the
> > faster is the application startup and smoother is the whole running.
> > I also noticed that having only one Xerces parser (in system classpath)
> > for both cocoon2 webapp and catalina improves notably the average
> > performance and memory footprint...
> > I don't have exact figures but we should start now to be aware of these
> > libraries sharing and Classloader issues.
>
> Oh, yes. Catalina's classloader is much slower compared to the system
> classpath. This is pretty obvious... but this is only at boot time, it
> doesn't make a real difference after you've loaded all the necessary
> classes.
>
But I can see how that would be a pain during development when you're
restarting a webapp all the time.
As it happens, over the weekend I installed a new class loader implementation
that extends the standard Java2 URLClassLoader instead of the home grown
version. This version is also in the "milestone 1" release. Could you guys
please try it again with the new one?
NOTE: This classloader currently implements auto-reload for classes in
WEB-INF/classes -- not for classes inside JAR files in WEB-INF/lib. This will
be fixed later, but should not normally be a problem in a development
environment, since most people won't waste the time to continually create JAR
files as they are modifying classes.
> As for memory footprint, this is pretty obvious, but it could lead to
> potential security problems.
>
> Craig, shouldn't we have a "safe" mode and a "normal" mode for
> classloading?
>
Webapp class loaders is one of the issues that was discussed quite a bit for
servlet 2.3. It's worth reviewing a little background info to bring people up
to date.
The current Catalina classloading strategy is to create the following kinds of
classloaders at startup time:
* The JVM (at least the Sun one) itself sets up the bootstrap
class loader with the contents of $JAVA_HOME/jre/lib/ext
(the system extensions you have installed) plus its own
basic runtime classes.
* The system class loader is configured to contain the
$CATALINA_HOME/bin/bootstrap.jar file, plus all the
jars in $CATALINA_HOME/lib. Any CLASSPATH
variable that the user currently has set is totally
ignored (I'm negotiable on this, but I'm really tired of all
the user problems related to class paths). The JAR files
here should be the ones required by more than one webapp.
The parent of this class loader is the bootstrap class loader.
* The Catalina class loader contains all of the implementation
classes of Catalina itself, and libraries it needs. This is created
automatically from the jar files in $CATALINA_HOME/server.
These classes are *not* exposed to webapps.
* The webapp class loader (one per webapp) is configured from
the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
webapp. It's parent class loader is the system class loader
(see above).
One of the big issues with any sort of "shared library" approach is, what do
you do when the same class appears in both the webapp class loader and the
system class loader? Which one wins?
In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
Java2 delegation model, and always goes to the parent first (i.e. the system
classpath), and then in the webapp. If you've got the same class both places
(like an XML parser or a JDBC driver), the one on the system classpath wins.
By the way, this is what caused so much grief in Tomcat 3.1 with people trying
to run their own parsers that had some classes in common with the "xml.jar"
parser shipped with 3.1.
In Tomcat 4.0, Catalina by default follows the new search order articulated as
a "recommendation" in the servlet 2.3 draft spec:
* WEB-INF/classes
* WEB-INF/lib/*.jar
* System class loader
so that a library found in the webapp will always win. This can be configured
out (although not very gracefully at the moment), but seems to meet the
majority of use cases better than the previous scheme.
>
> > So the first question would be : when an application share common library
> > (say DOM and sax packages), what are the benefits of delivering the war
> > Webapp file with the web-inf/lib conataining the duplicated library (for
> > cocoon the shared libraries are Xerces (since catalina can works with
> > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
>
> The first and basic advantage is ease of installation. Drag your war
> file and you're done.
>
> The second advantage is complete separation: no problem with class cast
> exceptions and all that since the web-inf/lib takes precedence (I like
> this very much)
>
The third advantage is that some libraries will not work correctly unless they
are installed in the webapp. I believe Cocoon has run into this -- I'll
describe what I ran into with Struts because it's similar.
Struts includes a module called Digester (very similar to the XmlMapper that is
used inside Tomcat to configure itself from the server.xml and web.xml files).
One of the things you can do is create a new object when a particular XML
element is encountered. But, if the digester classes are loaded from the
system class path, and the Java class of the object you're trying to create is
in the webapp (a very typical case), you're out of luck --
ClassNotFoundException because the Digester tries to use the classloader it was
itself loaded from (i.e. system class loader).
So, even though reducing the memory footprint (by sharing libraries) is very
appealing, it is not always going to be practical.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
See below.
Stefano Mazzocchi wrote:
> Sebastien Sahuc wrote:
> >
> > I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
> > annoyance.
> >
> > "Craig R. McClanahan" wrote :
> >
> > > Sebastien Sahuc wrote:
> >
> > > > Same with Catalina .... :-(
> >
> > > >
> > > > Any hint on why is it so slow to start the Catalina ?
> > > >
> >
> > > I don't remember if 3.2 does this, but Catalina logs when it starts and
> > > stops
> > > initializing the random number generator. It would be interesting to
> > > find
> > > out if that is the issue or not for you. By the way, this is done once
> > > per
> > > webapp (they use independent RNGs) so the number of different webapps
> > > you
> > > have defined matters.
> >
> > I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
> > file, and the more a remove -unecessary- jar files from web-inf, the
> > faster is the application startup and smoother is the whole running.
> > I also noticed that having only one Xerces parser (in system classpath)
> > for both cocoon2 webapp and catalina improves notably the average
> > performance and memory footprint...
> > I don't have exact figures but we should start now to be aware of these
> > libraries sharing and Classloader issues.
>
> Oh, yes. Catalina's classloader is much slower compared to the system
> classpath. This is pretty obvious... but this is only at boot time, it
> doesn't make a real difference after you've loaded all the necessary
> classes.
>
But I can see how that would be a pain during development when you're
restarting a webapp all the time.
As it happens, over the weekend I installed a new class loader implementation
that extends the standard Java2 URLClassLoader instead of the home grown
version. This version is also in the "milestone 1" release. Could you guys
please try it again with the new one?
NOTE: This classloader currently implements auto-reload for classes in
WEB-INF/classes -- not for classes inside JAR files in WEB-INF/lib. This will
be fixed later, but should not normally be a problem in a development
environment, since most people won't waste the time to continually create JAR
files as they are modifying classes.
> As for memory footprint, this is pretty obvious, but it could lead to
> potential security problems.
>
> Craig, shouldn't we have a "safe" mode and a "normal" mode for
> classloading?
>
Webapp class loaders is one of the issues that was discussed quite a bit for
servlet 2.3. It's worth reviewing a little background info to bring people up
to date.
The current Catalina classloading strategy is to create the following kinds of
classloaders at startup time:
* The JVM (at least the Sun one) itself sets up the bootstrap
class loader with the contents of $JAVA_HOME/jre/lib/ext
(the system extensions you have installed) plus its own
basic runtime classes.
* The system class loader is configured to contain the
$CATALINA_HOME/bin/bootstrap.jar file, plus all the
jars in $CATALINA_HOME/lib. Any CLASSPATH
variable that the user currently has set is totally
ignored (I'm negotiable on this, but I'm really tired of all
the user problems related to class paths). The JAR files
here should be the ones required by more than one webapp.
The parent of this class loader is the bootstrap class loader.
* The Catalina class loader contains all of the implementation
classes of Catalina itself, and libraries it needs. This is created
automatically from the jar files in $CATALINA_HOME/server.
These classes are *not* exposed to webapps.
* The webapp class loader (one per webapp) is configured from
the WEB-INF/classes and WEB-INF/lib/*.jar contents of this
webapp. It's parent class loader is the system class loader
(see above).
One of the big issues with any sort of "shared library" approach is, what do
you do when the same class appears in both the webapp class loader and the
system class loader? Which one wins?
In Tomcat 3.x (<= 3.2 at least), the webapp classloader follows the standard
Java2 delegation model, and always goes to the parent first (i.e. the system
classpath), and then in the webapp. If you've got the same class both places
(like an XML parser or a JDBC driver), the one on the system classpath wins.
By the way, this is what caused so much grief in Tomcat 3.1 with people trying
to run their own parsers that had some classes in common with the "xml.jar"
parser shipped with 3.1.
In Tomcat 4.0, Catalina by default follows the new search order articulated as
a "recommendation" in the servlet 2.3 draft spec:
* WEB-INF/classes
* WEB-INF/lib/*.jar
* System class loader
so that a library found in the webapp will always win. This can be configured
out (although not very gracefully at the moment), but seems to meet the
majority of use cases better than the previous scheme.
>
> > So the first question would be : when an application share common library
> > (say DOM and sax packages), what are the benefits of delivering the war
> > Webapp file with the web-inf/lib conataining the duplicated library (for
> > cocoon the shared libraries are Xerces (since catalina can works with
> > it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
>
> The first and basic advantage is ease of installation. Drag your war
> file and you're done.
>
> The second advantage is complete separation: no problem with class cast
> exceptions and all that since the web-inf/lib takes precedence (I like
> this very much)
>
The third advantage is that some libraries will not work correctly unless they
are installed in the webapp. I believe Cocoon has run into this -- I'll
describe what I ran into with Struts because it's similar.
Struts includes a module called Digester (very similar to the XmlMapper that is
used inside Tomcat to configure itself from the server.xml and web.xml files).
One of the things you can do is create a new object when a particular XML
element is encountered. But, if the digester classes are loaded from the
system class path, and the Java class of the object you're trying to create is
in the webapp (a very typical case), you're out of luck --
ClassNotFoundException because the Digester tries to use the classloader it was
itself loaded from (i.e. system class loader).
So, even though reducing the memory footprint (by sharing libraries) is very
appealing, it is not always going to be practical.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Stefano Mazzocchi <st...@apache.org>.
Sebastien Sahuc wrote:
>
> I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
> annoyance.
>
> "Craig R. McClanahan" wrote :
>
> > Sebastien Sahuc wrote:
>
> > > Same with Catalina .... :-(
>
> > >
> > > Any hint on why is it so slow to start the Catalina ?
> > >
>
> > I don't remember if 3.2 does this, but Catalina logs when it starts and
> > stops
> > initializing the random number generator. It would be interesting to
> > find
> > out if that is the issue or not for you. By the way, this is done once
> > per
> > webapp (they use independent RNGs) so the number of different webapps
> > you
> > have defined matters.
>
> I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
> file, and the more a remove -unecessary- jar files from web-inf, the
> faster is the application startup and smoother is the whole running.
> I also noticed that having only one Xerces parser (in system classpath)
> for both cocoon2 webapp and catalina improves notably the average
> performance and memory footprint...
> I don't have exact figures but we should start now to be aware of these
> libraries sharing and Classloader issues.
Oh, yes. Catalina's classloader is much slower compared to the system
classpath. This is pretty obvious... but this is only at boot time, it
doesn't make a real difference after you've loaded all the necessary
classes.
As for memory footprint, this is pretty obvious, but it could lead to
potential security problems.
Craig, shouldn't we have a "safe" mode and a "normal" mode for
classloading?
> So the first question would be : when an application share common library
> (say DOM and sax packages), what are the benefits of delivering the war
> Webapp file with the web-inf/lib conataining the duplicated library (for
> cocoon the shared libraries are Xerces (since catalina can works with
> it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
The first and basic advantage is ease of installation. Drag your war
file and you're done.
The second advantage is complete separation: no problem with class cast
exceptions and all that since the web-inf/lib takes precedence (I like
this very much)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Stefano Mazzocchi <st...@apache.org>.
Sebastien Sahuc wrote:
>
> I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
> annoyance.
>
> "Craig R. McClanahan" wrote :
>
> > Sebastien Sahuc wrote:
>
> > > Same with Catalina .... :-(
>
> > >
> > > Any hint on why is it so slow to start the Catalina ?
> > >
>
> > I don't remember if 3.2 does this, but Catalina logs when it starts and
> > stops
> > initializing the random number generator. It would be interesting to
> > find
> > out if that is the issue or not for you. By the way, this is done once
> > per
> > webapp (they use independent RNGs) so the number of different webapps
> > you
> > have defined matters.
>
> I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
> file, and the more a remove -unecessary- jar files from web-inf, the
> faster is the application startup and smoother is the whole running.
> I also noticed that having only one Xerces parser (in system classpath)
> for both cocoon2 webapp and catalina improves notably the average
> performance and memory footprint...
> I don't have exact figures but we should start now to be aware of these
> libraries sharing and Classloader issues.
Oh, yes. Catalina's classloader is much slower compared to the system
classpath. This is pretty obvious... but this is only at boot time, it
doesn't make a real difference after you've loaded all the necessary
classes.
As for memory footprint, this is pretty obvious, but it could lead to
potential security problems.
Craig, shouldn't we have a "safe" mode and a "normal" mode for
classloading?
> So the first question would be : when an application share common library
> (say DOM and sax packages), what are the benefits of delivering the war
> Webapp file with the web-inf/lib conataining the duplicated library (for
> cocoon the shared libraries are Xerces (since catalina can works with
> it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
The first and basic advantage is ease of installation. Drag your war
file and you're done.
The second advantage is complete separation: no problem with class cast
exceptions and all that since the web-inf/lib takes precedence (I like
this very much)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/25/2000 2:58 PM, "Sebastien Sahuc" <ss...@imediation.com> wrote:
> So the first question would be : when an application share common library
> (say DOM and sax packages), what are the benefits of delivering the war
> Webapp file with the web-inf/lib conataining the duplicated library (for
> cocoon the shared libraries are Xerces (since catalina can works with
> it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
The problem is the way that classloaders find the classes they need to load.
If you try to use Class.forName() for something that isn't in the right
classloader, then you are hosed. That is the reason.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Sebastien Sahuc <ss...@imediation.com>.
I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
annoyance.
"Craig R. McClanahan" wrote :
> Sebastien Sahuc wrote:
> > Same with Catalina .... :-(
> >
> > Any hint on why is it so slow to start the Catalina ?
> >
> I don't remember if 3.2 does this, but Catalina logs when it starts and
> stops
> initializing the random number generator. It would be interesting to
> find
> out if that is the issue or not for you. By the way, this is done once
> per
> webapp (they use independent RNGs) so the number of different webapps
> you
> have defined matters.
I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
file, and the more a remove -unecessary- jar files from web-inf, the
faster is the application startup and smoother is the whole running.
I also noticed that having only one Xerces parser (in system classpath)
for both cocoon2 webapp and catalina improves notably the average
performance and memory footprint...
I don't have exact figures but we should start now to be aware of these
libraries sharing and Classloader issues.
So the first question would be : when an application share common library
(say DOM and sax packages), what are the benefits of delivering the war
Webapp file with the web-inf/lib conataining the duplicated library (for
cocoon the shared libraries are Xerces (since catalina can works with
it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
Thanks for any reply,
Sebastien
> On JAR files, which JARs in particular are causing you grief? If I knew
> that
> I could investigate the same scenarios you guys are seeing.
> >
> > Sebastien
> >
> Craig
> >
> > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> >
> > On 9/25/00, 11:05:15 PM, costin@eng.sun.com wrote regarding Re:
> loading
> > of classes in tomcat 3.2b4 is _sloooooow_:
> >
> > > > Using Tomcat 3.1, Turbine starts up _really_ quickly.
> > > > Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
> > > >
> > > > Once things have initialized, everything runs very quickly.
> > > >
> > > > Turbine has a boat load of .jar files and doing some initial
> testing,
> > > I
> > > > suspect that something in Tomcat changed with regards to class
> file
> > > loading
> > > > because if I remove some of the .jar's that I know I'm not using
> then
> > > things
> > > > speed up.
> > > >
> > > > Costin, any ideas? This is painful.
> >
> > > I'm afraid not - the class loader is almost the same, plus some
> extra
> > > checking we need to do.
> >
> > > I'll try it - but I don't think there is any simple solution ( short
> of
> > > replacing the loader - that's what we already did for 3.3. )
> > > ( and the reason for not doing the same in 3.2 is stability -
> > > AdaptiveClassLoader is too well tested ).
> >
> > > Costin
> >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> --
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
Posted by Sebastien Sahuc <ss...@imediation.com>.
I'm crossposting the mail to cocoon-dev and tomcat-dev, sorry for the
annoyance.
"Craig R. McClanahan" wrote :
> Sebastien Sahuc wrote:
> > Same with Catalina .... :-(
> >
> > Any hint on why is it so slow to start the Catalina ?
> >
> I don't remember if 3.2 does this, but Catalina logs when it starts and
> stops
> initializing the random number generator. It would be interesting to
> find
> out if that is the issue or not for you. By the way, this is done once
> per
> webapp (they use independent RNGs) so the number of different webapps
> you
> have defined matters.
I have exactly one webapp which is cocoon2. Cocoon2 comes as a big WAR
file, and the more a remove -unecessary- jar files from web-inf, the
faster is the application startup and smoother is the whole running.
I also noticed that having only one Xerces parser (in system classpath)
for both cocoon2 webapp and catalina improves notably the average
performance and memory footprint...
I don't have exact figures but we should start now to be aware of these
libraries sharing and Classloader issues.
So the first question would be : when an application share common library
(say DOM and sax packages), what are the benefits of delivering the war
Webapp file with the web-inf/lib conataining the duplicated library (for
cocoon the shared libraries are Xerces (since catalina can works with
it), tools.jar (which is 4mg big!), jndi.jar, etc ...)
Thanks for any reply,
Sebastien
> On JAR files, which JARs in particular are causing you grief? If I knew
> that
> I could investigate the same scenarios you guys are seeing.
> >
> > Sebastien
> >
> Craig
> >
> > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> >
> > On 9/25/00, 11:05:15 PM, costin@eng.sun.com wrote regarding Re:
> loading
> > of classes in tomcat 3.2b4 is _sloooooow_:
> >
> > > > Using Tomcat 3.1, Turbine starts up _really_ quickly.
> > > > Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
> > > >
> > > > Once things have initialized, everything runs very quickly.
> > > >
> > > > Turbine has a boat load of .jar files and doing some initial
> testing,
> > > I
> > > > suspect that something in Tomcat changed with regards to class
> file
> > > loading
> > > > because if I remove some of the .jar's that I know I'm not using
> then
> > > things
> > > > speed up.
> > > >
> > > > Costin, any ideas? This is painful.
> >
> > > I'm afraid not - the class loader is almost the same, plus some
> extra
> > > checking we need to do.
> >
> > > I'll try it - but I don't think there is any simple solution ( short
> of
> > > replacing the loader - that's what we already did for 3.3. )
> > > ( and the reason for not doing the same in 3.2 is stability -
> > > AdaptiveClassLoader is too well tested ).
> >
> > > Costin
> >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> --
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Sebastien Sahuc wrote:
> Same with Catalina .... :-(
>
> Any hint on why is it so slow to start the Catalina ?
>
I don't remember if 3.2 does this, but Catalina logs when it starts and stops
initializing the random number generator. It would be interesting to find
out if that is the issue or not for you. By the way, this is done once per
webapp (they use independent RNGs) so the number of different webapps you
have defined matters.
On JAR files, which JARs in particular are causing you grief? If I knew that
I could investigate the same scenarios you guys are seeing.
>
> Sebastien
>
Craig
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 9/25/00, 11:05:15 PM, costin@eng.sun.com wrote regarding Re: loading
> of classes in tomcat 3.2b4 is _sloooooow_:
>
> > > Using Tomcat 3.1, Turbine starts up _really_ quickly.
> > > Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
> > >
> > > Once things have initialized, everything runs very quickly.
> > >
> > > Turbine has a boat load of .jar files and doing some initial testing,
> > I
> > > suspect that something in Tomcat changed with regards to class file
> > loading
> > > because if I remove some of the .jar's that I know I'm not using then
> > things
> > > speed up.
> > >
> > > Costin, any ideas? This is painful.
>
> > I'm afraid not - the class loader is almost the same, plus some extra
> > checking we need to do.
>
> > I'll try it - but I don't think there is any simple solution ( short of
> > replacing the loader - that's what we already did for 3.3. )
> > ( and the reason for not doing the same in 3.2 is stability -
> > AdaptiveClassLoader is too well tested ).
>
> > Costin
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by Sebastien Sahuc <ss...@imediation.com>.
Same with Catalina .... :-(
Any hint on why is it so slow to start the Catalina ?
Sebastien
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 9/25/00, 11:05:15 PM, costin@eng.sun.com wrote regarding Re: loading
of classes in tomcat 3.2b4 is _sloooooow_:
> > Using Tomcat 3.1, Turbine starts up _really_ quickly.
> > Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
> >
> > Once things have initialized, everything runs very quickly.
> >
> > Turbine has a boat load of .jar files and doing some initial testing,
> I
> > suspect that something in Tomcat changed with regards to class file
> loading
> > because if I remove some of the .jar's that I know I'm not using then
> things
> > speed up.
> >
> > Costin, any ideas? This is painful.
> I'm afraid not - the class loader is almost the same, plus some extra
> checking we need to do.
> I'll try it - but I don't think there is any simple solution ( short of
> replacing the loader - that's what we already did for 3.3. )
> ( and the reason for not doing the same in 3.2 is stability -
> AdaptiveClassLoader is too well tested ).
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by co...@eng.sun.com.
> Using Tomcat 3.1, Turbine starts up _really_ quickly.
> Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
>
> Once things have initialized, everything runs very quickly.
>
> Turbine has a boat load of .jar files and doing some initial testing, I
> suspect that something in Tomcat changed with regards to class file loading
> because if I remove some of the .jar's that I know I'm not using then things
> speed up.
>
> Costin, any ideas? This is painful.
I'm afraid not - the class loader is almost the same, plus some extra
checking we need to do.
I'll try it - but I don't think there is any simple solution ( short of
replacing the loader - that's what we already did for 3.3. )
( and the reason for not doing the same in 3.2 is stability -
AdaptiveClassLoader is too well tested ).
Costin
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/25/2000 1:17 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> Geoff Souter also ran into something like this, and determined that the delay
> in
> his case was do to exactly this. Removing all the signing stuff from the JAR
> files took care of it.
gag...but a lot of these .jar files are Sun .jar files and I'm afraid to
change/touch them. Is there a way to turn off the checking within Tomcat?
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Aaron Mulder wrote:
> We saw something like this on jBoss once, and I think the slowdown
> was the security system checking access permissions on all the JARs. When
> we put certain things on the main classpath instead of elsewhere, it got
> way faster. Just a thought - I know Tomcat has a boatload of ClassLoaders
> just like jBoss. As you can tell, I'm a little hazy on the specifics, but
> I think Rickard detailed it on the mailing list, so you could search the
> archives at http://www.jboss.org/mailing.htm
>
Geoff Souter also ran into something like this, and determined that the delay in
his case was do to exactly this. Removing all the signing stuff from the JAR
files took care of it.
Another possibility is that you're seeing the delay for initializing the random
number generator (SecureRandom), which can take multiple seconds on some
platforms.
>
> Aaron
>
Craig
>
> On Mon, 25 Sep 2000, Jon Stevens wrote:
> > Ok,
> >
> > Using Tomcat 3.1, Turbine starts up _really_ quickly.
> > Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
> >
> > Once things have initialized, everything runs very quickly.
> >
> > Turbine has a boat load of .jar files and doing some initial testing, I
> > suspect that something in Tomcat changed with regards to class file loading
> > because if I remove some of the .jar's that I know I'm not using then things
> > speed up.
> >
> > Costin, any ideas? This is painful.
> >
> > -jon
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: loading of classes in tomcat 3.2b4 is _sloooooow_
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
We saw something like this on jBoss once, and I think the slowdown
was the security system checking access permissions on all the JARs. When
we put certain things on the main classpath instead of elsewhere, it got
way faster. Just a thought - I know Tomcat has a boatload of ClassLoaders
just like jBoss. As you can tell, I'm a little hazy on the specifics, but
I think Rickard detailed it on the mailing list, so you could search the
archives at http://www.jboss.org/mailing.htm
Aaron
On Mon, 25 Sep 2000, Jon Stevens wrote:
> Ok,
>
> Using Tomcat 3.1, Turbine starts up _really_ quickly.
> Using Tomcat 3.2b4, Turbine starts up _really_ slowly.
>
> Once things have initialized, everything runs very quickly.
>
> Turbine has a boat load of .jar files and doing some initial testing, I
> suspect that something in Tomcat changed with regards to class file loading
> because if I remove some of the .jar's that I know I'm not using then things
> speed up.
>
> Costin, any ideas? This is painful.
>
> -jon
>
>