That probably explains why I got "null". ClassLoader.getResource is a
lot simpler than the approach I used...
David
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12359108 ]
Daniel John Debrunner commented on DERBY-668:
---------------------------------------------
The comment for ClassLoader.getResource says:
a URL for reading the resource, or null if the resource could not be found or
the caller doesn't have adequate privileges to get the resource.
Thus if you don't have permission to read the class you should get null back.
Not sure how this affects this patch, I know in the class loader that loads
from the database I implemented to return null for any request for a file
ending in .class, I'd just assumed most class loaders did that.
SysInfo can give misleading information when JDBC jars are loaded from
jre/lib/ext
----------------------------------------------------------------------------------
Key: DERBY-668
URL: http://issues.apache.org/jira/browse/DERBY-668
Project: Derby
Type: Bug
Components: Build tools
Versions: 10.1.1.0
Reporter: Bryan Pendleton
Priority: Minor
Attachments: Derby-668.diff, derby-668-2.diff, derby-668-3.diff
There is a section in the SysInfo tool's output titled "Derby Information",
which prints location and version information for the major Derby jars. Here is an
example of that output:
--------- Derby Information --------
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derby.jar] 10.2.0.0
alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbytools.jar]
10.2.0.0 alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbynet.jar] 10.2.0.0
alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbyclient.jar]
10.2.0.0 alpha - (315052M)
[/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc.jar] 2.4 - (17)
[/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17)
Unfortunately, this tool can be fooled if you arrange for one of these jar
files to be loaded from a magic location like $JAVA_HOME/jre/lib/ext.
For example, I had (accidentally) placed an old version of db2jcc.jar into $JAVA_HOME/jre/lib/ext. When I ran SysInfo, it printed out:
--------- Derby Information --------
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derby.jar] 10.2.0.0
alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbytools.jar]
10.2.0.0 alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbynet.jar] 10.2.0.0
alpha - (315052M)
[/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbyclient.jar]
10.2.0.0 alpha - (315052M)
[/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc.jar] 1.0 - (581)
[/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc_license_c.jar] 1.0 - (581)
However, the "1.0 (581)" information actually came from
$JAVA_HOME/jre/lib/ext/db2jcc.jar, NOT from
/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc.jar.
It would be nice if SysInfo could detect the difference between a jar file
being loaded via the application class loader using $CLASSPATH, and a jar file
being loaded via the system class loader using JDK library extensions.
To reproduce the problem, simply:
1) Place an older version of db2jcc.jar into $JAVA_HOME/jre/lib/ext
2) Place a newer version of db2jcc.jar into your $CLASSPATH
3) Run SysInfo. You will see that it prints the name of the jarfile from
$CLASSPATH, but the version info from the JDK copy.
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
