Jerome Dochez wrote:
>
> 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...
We already have a filtering mechanism inside the WebappClassloader.
Might not be the best, but I know it works :-)
>
>> 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
Ya now I recall the JSF/MyFaces troubles :-)
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 ;-)
...and welcome new nightmares :-)
>
> overall I think we need to rethink the web app class loader, maybe we
> should have a 1 hour virtual meeting all of us.
Dangerous.....but doable ;-) +1
-- Jeanfrancois
>>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>> if not, what is the exact list of classes that a web application
>>> class loader should directly have access to ?
>>
>>
>>
>>
>>>
>