Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <331724808.1141082459779.JavaMail.jira@ajax.apache.org>
Date: Tue, 28 Feb 2006 00:20:59 +0100 (CET)
From: "Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-668) SysInfo does not print the right
 information when Derby is not loaded through the classpath.
In-Reply-To: <1153567093.1130883415407.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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

Andrew McIntyre commented on DERBY-668:
---------------------------------------

Hi Bryan,

This looks good to me. Dan would need to comment on the security ramifications of needing the getProtectionDomain permission.

If you have a chance, take a look at my patch for DERBY-1063, it includes a fix to the 'regular' sysinfo (no arguments) case, although it uses getResource() which Dan said might be a problem, although it only loads properties files, not class files. I think the combination of your patch and my patch may cover most of the cases as far as reporting the proper locations of files, or at least the ones we can get to through the default classloader and the classpath. (which would be the ones that mattered, i suppose if you're running sysinfo in the same environment as your classloading/classpath setup.)

> 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