When we were working on V2, there was discussion of completely
refactoring the overly-complex classloading hierarchy because this
causes us performance issues in lots of places. It was too complex for
V2, but that was supposed to be looked at again for V3 -- is that
anywhere on the radar screen for V3?
-Scott
On Wed, 2008-02-27 at 13:10, Jerome Dochez wrote:
> JF, Jan, Amy and Shing Wai
>
> Some of you may have seen the email I sent few minutes back on grails
> deployment in V3 which took 9 minutes rather than 9 seconds. I traced
> down the problem to a combination of factors :
>
> - the webapp class loader likes to delegate up the requests for
> loading classes which is right in most cases.
> - the parent of the web app class loader has the webtier module in
> its list of imported modules, the webtier module itself has a pretty
> healthy list of imports.
>
> So each time a class need to be loaded, the modular subsystem is
> looking through a rather big network of module's class loaders to not
> find the requested classes (which happens to be bundled in the war
> file).
>
> To fix this, we need to stop having the entire webtier classes
> visibile to the web applications (my current hack is based on that,
> where basically, the web app can only load the
> org.apache.jasper.servlet.JspServlet class, through a punching
> mechanism) That's enough to load simple web apps and grails app. Of
> course we need to come up with the exact list of classes that a web
> application should be able to see.
>
> Do you see another solution ?
>
> if not, what is the exact list of classes that a web application class
> loader should directly have access to ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>