The classloader work I did I think includes something that can help
solve this problem. You can find out where a given class was loaded
from without searching the classpath. So you could do what I think
Brian suggested, load a class from each jar file and then find out where
that jar file came from and print it out.
If someone has an itch to fix these bugs, I can show them what I did
David
Bryan Pendleton wrote:
Daniel John Debrunner (JIRA) wrote:
sysinfo does not report the version of derby.jar if the class does not
explictly contain it.
I think this is very closely related to
http://issues.apache.org/jira/browse/DERBY-668
which we were discussing a few months ago.
The basic issue is that the algorithm used by
sysinfo in its "standard" mode relies on simple
textual parsing of the CLASSPATH value, and so it
misses subtleties such as standard extensions,
jar-linked jars, etc.
sysinfo with the '-cp' flag is better in some ways,
because instead of
"for each library in CLASSPATH, what classes does it contain?"
the algorithm is more like
"for each signature class that I'm interested in, can I load it?"
Either way, I think that the problem with sysinfo is less of
a coding problem than it is a requirements problem.
That is, if we could clearly state what it is that we wanted
sysinfo to do, I think Java offers the tools to allow us to code it.
I'd be willing and interested to extend the change that I proposed
to DERBY-668 to cover this problem as well, if I can get some help
from the community in improving our understanding of the sysinfo
requirements.
thanks,
bryan
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
