On 10/01/2012 10:43, Rainer Jung wrote: > I wonder whether we want to improve caching in the WebappLoader. Of > course most deployments no longer use shared or common to share many > application classes, but it is still a supported feature and for some > classes like JDBC it is standard.
I think at least providing the option to do so would be a good idea. > 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. > > - increased memory use for the cache, i.e. the list of class names and > references to the classes. > > To stay completely compatible I think the feature should not be default, > at least until TC 7, maybe switch default for 8. > > What do you think? Does it make sense? Should I prepare a patch for trunk? This makes sense for this specific use case. I'd lean towards making this disabled by default since the benefits only kick in for a less used use case but the disadvantages apply in all cases. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
