DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32369>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32369 ------- Additional Comments From [EMAIL PROTECTED] 2004-12-01 21:33 ------- Just pulling a reference book from my shelf with the javadoc: "The default implementation of this method does nothing;" - as you indicated. "Subclasses of ClassLoader should override this method..." Thoughts: 1. "should" versus "shall" or "must". Acknowledge the issue, but maintain I have a right to consider this expected behavior. 2. Use of "loadClass". I put a lot of thought into making this performant... potentially there can be multiple hits on a resource, and I don't want to load all the classes. Consider the situation where discovery locates multiple XML parsers... do you really want it to load all of them? No. You want your application to determine which one it wants... or you want the discovery helper classes to load the first one only. 3. Discovery does more than load classes, it locates any resource available from the classloader. Do to this (nested jars within jars?) it works on and is capable of returning lists of resource names (URLs) which can be individually loaded. Again, for performance reasons we don't want to force loading of these resources - we want to discover & report.. and let the applicaiton drive loading. *AGAIN* Bottom line, a ClassLoader that does not support discovery of resources is, by my definition/understanding of the goals/purposes of discovery, not usable by discovery. Some elements of discovery *may* be able to be made to work [as you have shown] with impacts on performance.. but are not generally useful. In this case, with your patch, discovery may locate your class, but would be unable to locate other resources within that nested jar file (property files, META-INF/services/*, whatever)... a further patch would be necessessary [getResourceAsStream] which only compounds the resource problem I raise. So, we have a conflict here I suppose we need to resolve. Anyone else care to comment on the performance issue of using loadClass [runtime AND memory] and getResourceAsStream versus a more "adaptable" discovery mechanism that works with err.. 'partial' ClassLoader implementations? Is there a URL/URI pattern that covers nested jar files that would be meaningful and useful for such a classloader? <ras> -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
