db-derby-dev mailing list archives

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


Mime
View raw message