On Feb 27, 2008, at 10:38 AM, Jeanfrancois Arcand wrote:
> Hi,
>
> 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.
>
> Hum..security wise, it's not good as it means people can snif
> org.apache.catalina code. It's hard for me to recall, but did we
> have those classes in the parent as well in v2?
oh yes we do :( but things work better because we have one huge class
loader that loads everything so the delegation stops there quite
rapidly athough as Scott mentioned, I am not surprised it had
performance impacts...
> I think we had them because back in 2003 in Tomcat 5, we added a
> security mechanism to prevent a web app to load org.apache classes
> directly. We never enabled the mechanism in GlassFish, but I know it
> is quite easy to hack the container :-)
>
>
>> 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 ?
>
> For sure you need org.apache.jasper.* and some of the
> org.apache.catalina/tomcat (need to look at the generated JSP). I
> think Kin-Man is the best person to list the classes, but this is
> quite dangerous IMO to block the load of those classes.
>
I want to block the other classes, not those. the trick is to be sure
we find the right set...
> Why the WEB-INF/lib/*.jar no longer added to the WebappClassloader?
it is added of course. no change here.
> Because if added, we wouldn't have to invoke the parent classloader
> and those classes would be loaded much faster...like it was in v2
> (against, I might me wrong ... long time I've broken something
> there :-))
no since there is delegation it goes to the parent first and the look
into WEB-INF/lib classes and that's what cause the trouble in v3
because going to the parent is a lot more expensive than it was,
especially that the parent contains all the webtier plus whatever it
imports (half of the appserver really...).
unless we want to make the delegation to false by default again ;-)
overall I think we need to rethink the web app class loader, maybe we
should have a 1 hour virtual meeting all of us.
>
>
> A+
>
> -- Jeanfrancois
>
>
>> if not, what is the exact list of classes that a web application
>> class loader should directly have access to ?
>
>
>
>
>>