yeah I think this is way too complex, it's time to break one more
thing :)
of u remember, could you elaborate on the perf issues you saw in v2, I
would love to avoid repeating the same mistakes...
thanks, Jerome
On Feb 27, 2008, at 10:20 AM, Scott Oaks wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>