Rainer, On 1/10/12 5:43 AM, Rainer Jung wrote: > Now loadClass() in the WebappClasLoader does: > > - check own class cache > - check super class cache > - try loading from system loader > - call Class.forName with parent loader (which calls loadClass() there) > [only if "delegated", which is *not* the default] > - try loading via findClass() > - call Class.forName with parent loader (which calls loadClass() there) > [only if not "delegated", which *is* the default]
Hmm. > What we could do to keep the design simple is caching any positive > result from loadClass() in the WebappLoader, even it it was found via > super, system or parent. In addition we could also cache negative > results for all those. The biggest downsides I can see would be > > - less dynamics: if someone had a more dynamic loader unerneath ours, > which would change the result of loadClass() during runtime, we would > shield the app from it, because we now return classes from our cache. -0? Their CL should have the opportunity to load the class first, so it doesn't matter whether or not we cache the result, right? > - increased memory use for the cache, i.e. the list of class names and > references to the classes. -1 The class names (String) and Class objects will already be in memory because they will be stored by the "real" ClassLoader that loaded them. The only thing we will have to do is pay for the additional storage of those references in our own cache -- so, it's just the cost of the additional space from our own class mapping table. > To stay completely compatible I think the feature should not be default, > at least until TC 7, maybe switch default for 8. This could be implemented as a separate WebappClassLoader, and configured in the <Context>. That way users can choose, and the default is the old behavior. > What do you think? Does it make sense? Should I prepare a patch for trunk? +1 -chris
signature.asc
Description: OpenPGP digital signature
