commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32369] - [discovery] Doesn't work with ClassLoaders that do not support getResource()
Date Wed, 01 Dec 2004 20:33:44 GMT
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 rsitze@apache.org  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message