My experience has been this works with classes in the classes directory
but not in jar files. I am using the privileged action
Class.getProtectionDomain().getCodesource()
and it works well. It does need to be run in a privileged block and you
need to give permissions to the jar file using it. An example of this
is coming with my patch, and I was going to propose modifying Bryan's
work to use the utility routine I've written for just this purpose.
David
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12359101 ]
Daniel John Debrunner commented on DERBY-668:
---------------------------------------------
Is this code used?
+ // Given a loaded class, and the name by which we loaded that class, this
+ // routine asks the class's class loader for information about where the
+ // class was loaded from. Typically, this is a file, which might be
+ // either a class file or a jar file. The routine figures that out, and
+ // returns the name of the file. If it can't figure it out, it returns null
+ private static String getFileWhichLoadedClass(Class c, String cName)
+ {
+ String className = "/" + cName.replace('.', '/') + ".class";
+ java.net.URL url = c.getResource(className);
because I thought a class loader was not allowed to return the .class file as a
resource for security reasons.
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
