On Feb 27, 2008, at 11:24 AM, Jeanfrancois Arcand wrote:
>
>
> 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 :-)
yes but here we would end up filtering everything but a few things, I
becomes less expensive to check for the authorized access than filter
what shouldn't be accessed.
>
>
>
>>> 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 :-)
yep...
>
>
>
> 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
>
ok so can we meet this afternoon or tomorrow, I need to have
availabilities from everyone.
thanks, Jerome
> -- Jeanfrancois
>
>>>
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>> if not, what is the exact list of classes that a web application
>>>> class loader should directly have access to ?
>>>
>>>
>>>
>>>
>>>>