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 03:15 ------- Can you clarify what documented behaviour you are referring to? There is nothing in the ClassLoader JavaDoc documentation that says getResource must also allow access to class data. They do mention that a ClassLoader might construct class byte-code internally (thus there would not be a corresponding URL, without the ClassLoader also implementing a custom URL protocol handler). > suggestion. If the discovery community can determine a reasonable design > based on your scenario, we would be in a position to accept volunteer work to > implement that design :-) What is wrong with just calling loadClass() (since it is finding classes that I'm worried about here, not resources)? I patched DiscoverClasses to use that instead, and it seems to work fine. It allows me to use Axis inside this plugin environment now, whereas previously I could only use Sun's JWSDP. I'll attach a patch against current CVS. As for discovering resources rather than classes, perhaps the system could fall back to seeing whether getResourceAsStream returns non-null (in fact that is what the first version of my DiscoverClasses patch did, since the ClassLoader I'm working with did allow this type of access to the class data). I'm not sure which of your classes that would fit into though. -- 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]
