dev@glassfish.java.net

Re: Webtier classes visibility to web apps.

From: Shing Wai Chan <Shing-Wai.Chan_at_Sun.COM>
Date: Wed, 27 Feb 2008 12:48:39 -0800

I am ok tomorrow except noon to 1:00pm as I have a staff meeting.

Jerome Dochez wrote:
>
> 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 ?
>>>>
>>>>
>>>>
>>>>
>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>