Summary: | JreMemoryLeakPreventionListener enhancement to load configurable classes | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Sylvain Laurent <slaurent> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 7.0.21 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Sylvain Laurent
2011-09-21 21:56:46 UTC
Committed to trunk and tc7, will be available in tomcat 7.0.22. Proposed backport to tc6 http://svn.apache.org/viewvc?rev=1174359&view=rev Added to 6.0 in r1181719 and will be in 6.0.34. It seems like this feature could be used to reduce the amount of code in JMLPL by providing a default list of classes to load, since that's mainly what's going on in there. Is that worth it, or is it better to handle the cases we already handle and leave this feature for use with webapp-specific (e.g. private) classes? If you have predefined list of classes, what will this configuration property do: add to it, or replace it? If it adds to it, how you remove items from predefined list (that is currently done by setting some properties to false) - by editing catalina.properties? In general it makes sense, because it is easier to edit some default list (if we have to add some new classes to it in the default configuration) than introduce new setters and property name. It would indeed simplify JMLPL but would break the existing "API" if the setters and getters were removed. Or we can refactor to have the flag setters merely add some known class names to the set of classes to load. Konstantin: good point about add/remove/replace... I hadn't thought too hard about that. Some of the classes loaded should only be loaded if the user wants them loaded (e.g. AWT-related stuff, optional libraries, etc.) so there probably shouldn't be a far-reaching default. Sylvain: the API can be (somewhat) simply refactored to modify a list of classes to load. I'll think about it and log another enhancement request with a more well-thought-out description. |