[jira] Commented: (DERBY-668) SysInfo can give misleading information when JDBC jars are loaded from jre/lib/ext

["Bryan Pendleton (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12356832 ] 

Bryan Pendleton commented on DERBY-668:
---------------------------------------

I think that JavaWorld tip 105 can be used here: http://www.javaworld.com/javaworld/javatips/jw-javatip105.html.

In particular, I think that the following code, if inserted at the right place, enables the sysinfo utility to do a better job of printing out *exactly* the location where the DB2 JDBC driver was loaded from:

  this.getClass().getResource("/com/ibm/db2/jcc/DB2Driver.class").getFile()

When I compile and run this code in a standalone Java program, experimenting with various combinations of db2jcc.jar in the classpath versus db2jcc.jar in $JAVA_HOME/jre/lib/ext, the code appears to reliably figure out the actual location from which DB2Driver.class is found.

So I think it should be possible to use this code in derby/impl/tools/sysinfo/Main.java to print a better message about the location from which various classes are loaded.

However, I'm getting a little lost trying to figure out sysinfo/Main.java and sysinfo/ZipInfoProperties.java. :(

It seems to me like the current SysInfo program basically takes the approach of parsing the CLASSPATH variable and printing out information about the things it finds there.

That algorithm works well, except that it is defeated by "magic" locations like $JAVA_HOME/jre/lib/ext.

Therefore, it seems like SysInfo needs to be enhanced to use an additional algorithm like the one I propose above, which is to ask the classloader itself for a file-scheme URL to the actual location of the critical class files, and then to print that information out.

Anyway, that's as far as I got today, and I wanted to record that investigation so I wouldn't lose it.


> 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

>
> 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