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 22:14 ------- As a bystander, I find myself kind of ambivalent. My first response was to agree with Craig and Richard: the classloader must be broken. But I also find valid Len's point that the ClassLoader may be constructing a class' bytecode internally, therefore there may not be a corresponding URL. It's also true that while Richard's overall vision/architecture for Discovery is more wide-ranging, I think it's also true that most people want to use it to load classes, and probably in many cases, they just want to load the first one on the classpath. Since the patched method is specifically about returning ResourceClass objects whose sole purpose is to return an instance of java.lang.Class, why not simply use Len's patch as an "if (url == null)" block. While at it, why not hold on to the class returned by loadClass and pass it to the ResourceClass constructor which actually takes a Class object. There's perhaps a small hitch in passing in a null URL, should someone call the getResourceAsStream method which ResourceClass inherits, especially if as Len describes, these unusual ClassLoader implementations could return the resource as a stream if you asked it directly. You could probably fix that with a custom subclass of ResourceClass if it really seemed necessary. -- 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]
