[ 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: 10.1.1.0
> Reporter: Bryan Pendleton
> Assignee: Bryan Pendleton
> Priority: Critical
> Fix For: 10.2.0.0
> 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] 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
