DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12481>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12481 Method DTMManager.newInstance causes unnecessary memory consumption [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2003-01-15 19:22 ------- I've committed a patch for this bug. I will include a copy of the cvs comments in the commit: Before this commit, DTMManager.newInstance cached the found class in the cases where the class was identified in jaxp.properties or the class path. There were some problems with this: 1. It was not thread-safe because access to the static field foundFactory was not synchronized. 2. We weren't caching the class when we defaulted to the fallback class (this was the original issue in the bug report.) 3. We weren't using the AccessController class available in JDK1.2 to control acess to priviliged resources (eg. system properties, files). 4. DTMManager would never be specified in jaxp.properties because it's not part of the JAXP specification. 5. We aren't using context class loaders. So, I have made the following changes: 1. Taken the FactoryFinder, SecuritySupport and SecuritySupport12 classes from the JAXP subdirectories (in xml-commons) and used them as the basis for the lookup of the DTMManager class. This gives us the AccessController code. 2. Removed the context class loader support and added a cache for the found class (which gets used if the system property is not set.) If we want context class loader support in the future (which we probably do), then we will need to revisit this to see if caching the class loader and the class would work. 3. Synchronized access to the found class. 4. Instead of looking in jaxp.properties, look in xalan.properties (a xalan specific configuration file) which can be placed in <$JAVA_HOME>/jre/lib. Possible issues: 1. In general, using a cache means that the class will not change, regardless of changes to xalan.properties or the class loader.
