db-derby-dev mailing list archives

[jira] Commented: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.

Date

Tue, 21 Mar 2006 17:01:58 GMT

[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12371258 ]
Bryan Pendleton commented on DERBY-668:
---------------------------------------
It turns out that there are several tests which run the 'sysinfo' code in situations in which
a Java security manager is in place, and in these tests the code is not currently being granted
the permissions necessary to display the new detailed information which is added by this
patch.
The tests are:
- derbynet/sysinfo.java
- derybnet/sysinfo_withproperties.java
- demo/RunClassPathTester.java
The two sysinfo tests run the Network Server under a security manager, and then call the 'sysinfo'
command in client/server mode to print the sysinfo output from that Network Server. But the
Network Server is not granted the permission to read java.class.path, so that part of the
sysinfo output is blank.
The RunClassPathTester.java test runs the standalone sysinfo tool under a security manager,
passing it the '-cp' flag to print information about Database.class and SimpleApp.class. These
classes are indeed in the class path, but the test is not granted the permission to get the
ProtectionDomain and CodeSource for them.
The result, right now, is that the two Sysinfo tests now produce a new line of output stating
that permission has not been granted to read the java.class.path property, and the RunClassPathTester
test now produces a new line of output stating that permission has not been granted to get
the ProtectionDomain.
I think that output is correct, and so I am tempted to update the master output files to reflect
this new correct output.
Alternatively, I could modify derby_tests.policy to grant additional permissions to the Derby
codebase(s).
What is the better path to pursue?
> 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,
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