[ http://issues.apache.org/jira/browse/DERBY-668?page=all ]
Bryan Pendleton updated DERBY-668:
----------------------------------
Attachment: sysinfo_Feb27_2006.diff
Here's another version of the patch for review.
The primary difference between this version and the previous 30-Nov-2005
version is that I've switched to using the
getProtectionDomain().getCodeSource() technique proposed by David vanCouvering.
I picked up the code from a patch proposal to DERBY-930, I believe, and copied
the 5 lines or so here for use by Sysinfo.
Here's a few remarks:
- I've tested this code on Linux and Windows, with various combinations of
jars and classes in the classpath and in the JRE/lib/ext, with and without a
Security Manager in place, using various combinations of sysinfo arguments.
Unfortunately, there are a *lot* of permutations here, and I probably missed
some. Still, for the cases I tested, it behaved well.
- Running sysinfo -cp works pretty well with a Security Manager, but running
sysinfo *without* the -cp argument fails pretty badly under a Security Manager,
as Andrew commented earlier in this issue. I didn't try to fix those problems,
though I added a print statement for one particularly egregious case in which a
security exception while fetching the CLASSPATH value was quietly swallowed
with no output. Now it will at least tell you why it failed to process your
CLASSPATH.
- To run sysinfo -cp with a Security manager, you need a trivial policy file.
I used:
grant { permission java.lang.RuntimePermission
"getProtectionDomain"; };
which obviously isn't ideal, but it was sufficient for testing.
- I also did some testing of the case raised by Knut Anders, in which having
derbyclient.jar in the manifest of derbytools.jar causes derbyclient.jar to be
pulled from the same directory where derbytools.jar was loaded, even if you
have some other derbyclient.jar in your classpath. In my testing, "sysinfo -cp"
behaves correctly in this case, and reports the *real* derbyclient.jar that is
in use, which is good. Unfortunately, the code which explicitly parses the
classpath (sysinfo with no arguments) is still fooled by this case and gives a
misleading response.
Fundamentally, as I said in my 23-Nov-2005 comment, I think that the algorithm
used by Main.getAllInfo() is just an inferior algorithm. Textual parsing of the
CLASSPATH entry is just too easily fooled by a variety of modern class loading
situations.
But I think that the algorithm used by "sysinfo -cp" is fundamentally sound,
and I think that this patch improves it to make sysinfo better than it was,
even if it's not where we want it to be, yet.
Please have a renewed look at this patch, and tell me what you think.
thanks,
bryan
> SysInfo does not print the right information when Derby is not loaded through
> the classpath.
> --------------------------------------------------------------------------------------------
>
> 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
> Assignee: Bryan Pendleton
> Priority: Critical
> Attachments: Derby-668.diff, derby-668-2.diff, derby-668-3.diff,
> derby-668-4.diff, sysinfo_Feb27_2006.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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
