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 can give misleading information when JDBC jars are loaded from jre/lib/ext
Date Wed, 30 Nov 2005 22:18:31 GMT
     [ http://issues.apache.org/jira/browse/DERBY-668?page=all ]

Bryan Pendleton updated DERBY-668:

    Attachment: derby-668-3.diff

Hi Kathey, please consider this most recent patch. I've reverted the handling of db2jcc_license_c.jar
back to the pre-patch behavior, to wit: if we find db2jcc_license_c.jar in the classpath,
and if we are also able to load some version of the DB2Driver class or the DB2Version class,
then we display the db2jcc_license_c.jar file that we found in the classpath, and we also
display the version number information that we fetched from DB2Driver/DB2Version.

Here's a bunch of the various tests I ran; in all the cases, I think that the output of the
new SysInfo is correct, but I'd like you to confirm my results, please :)

1, 2) java -cp derby.jar:derbytools.jar sysinfo [-cp]
3, 4) java -cp derby.jar:derbytools.jar:db2jcc.jar sysinfo [-cp]
5, 6) java -cp derby.jar:derbytools.jar:db2jcc.jar:db2_license_c.jar sysinfo [-cp]
7, 8) java -cp derby.jar:derbytools.jar:db2_license_c.jar sysinfo [-cp]
9, 10) (with db2jcc.jar in $JAVA_HOME/jre/lib/ext), java -cp derby.jar:derbytools.jar:db2_license_c.jar
sysinfo [-cp]

Cases (7) and (8) are particularly interesting. Both the current sysinfo, and the one with
my patch, print no information about db2jcc_license_c.jar if we cannot load any version of
the DB2Driver or DB2Version classes. I think this is reasonable, but I'd like to hear your
opinion on this.

An alternate implementation would be, as you suggested in your comment, to print a line for
db2jcc_license_c.jar in this case, but don't print any version information. I guess I don't
know how important this is. In your comment, you noted that the primary user mistake was to
have db2jcc.jar, but not db2jcc_license_c.jar, rather than vice-versa, so I don't know if
it's worth adding a bunch more code to try to do something useful about the case where we
have db2jcc_license_c.jar in the classpath, but NOT db2jcc.jar. Please tell me what you think.



> SysInfo can give misleading information when JDBC jars are loaded from jre/lib/ext
> ----------------------------------------------------------------------------------
>          Key: DERBY-668
>          URL: http://issues.apache.org/jira/browse/DERBY-668
>      Project: Derby
>         Type: Bug
>   Components: Build tools
>     Versions:
>     Reporter: Bryan Pendleton
>     Priority: Minor
>  Attachments: Derby-668.diff, derby-668-2.diff, derby-668-3.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