db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.
Date Mon, 27 Feb 2006 20:14:56 GMT
     [ 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
 - 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.



> 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:
>     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] alpha -
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbytools.jar] alpha
- (315052M)
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbynet.jar] alpha
- (315052M)
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbyclient.jar] 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] alpha -
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbytools.jar] alpha
- (315052M)
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbynet.jar] alpha
- (315052M)
> [/home/bpendleton/src/derby-subversion/trunk/jars/insane/derbyclient.jar] 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:
For more information on JIRA, see:

View raw message