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 Tue, 27 Jun 2006 14:54:32 GMT
     [ http://issues.apache.org/jira/browse/DERBY-668?page=all ]

Bryan Pendleton updated DERBY-668:

    Derby Info: [Release Note Needed]

Here's a release note:

      PROBLEM: Sysinfo classpath information was insufficiently detailed

      SYMPTOM: Sometimes it was hard to tell where the Derby classes were actually being loaded
from in the JVM

      CAUSE: the algorithm that sysinfo used for analyzing and reporting on the application
classpath was not robust.

      SOLUTION: The sysinfo tool now prints additional information about the origin of the
classes and jars that it examines. The origin of a class might be: an entry in the application
classpath, an entry in a class loader location
list, a jar fetched due to being listed in the manifest entry of another jar, a standard extension
in the JRE's extensions directory, a jar installed into the application server, or any of
various other possibilities.

      Note that when sysinfo runs under a Java security manager, it may need special permissions
to access this additional information, including the permission to read the java.class.path
property, and the permission to call getProtectionDomain on a class. If sysinfo is not granted
these permissions, it will display an error message about the security problem in place of
displaying the class origin information.

    SECURITY NOTE: The new permissions are optional. If you do not provide them, you will
see a message such as the following in your sysinfo output: Unable to analyze class path:
access denied (java.util.PropertyPermission java.class.path read). Such a message does not
indicate an error; it simply means that the sysinfo tool was unable to provide detailed classpath
information because it did not have permission to read the classpath. In prior releases, under
these circumstances, sysinfo would silently print nothing, now it prints an informational
message about the reason that it couldn't provide any classpath information.

> 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
>      Fix For:
>  Attachments: Derby-668.diff, derby-668-2.diff, derby-668-3.diff, derby-668-4.diff, sysinfo_Feb27_2006.diff,
sysinfo_Feb28_2006.diff, with_andrews_feedback.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