[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12358869 ]
Bryan Pendleton commented on DERBY-668: --------------------------------------- That's an interesting point. I think that the line in question was rather misleading, though: [/D:/p4/marsden_patch/drda/jcc/2.4/db2jcc.jar] 2.4 - (17) The "2.4 - (17)" in this line is printing the results of calling DB2Driver.getMajorVersion() (2), DB2Driver.getMinorVersion (4), and DB2Driver.getJCCBuildNumber() (17). But, we're calling these methods on the DB2Driver which is in db2jcc.jar! That is, from what I can tell, sysinfo is claiming to report that db2jcc_license_c.jar is version 2.4, build 17, but it's not actually using any information from db2jcc_license_c.jar to derive that information. I don't know that db2jcc_license_c.jar even has a concept of a version number. >From what I can see, it has only a MANIFEST, and a single file, namely com.ibm.db2.jcc.licenses.DB2J. Is there any documentation available on the DB2J class? It would be easy to alter the proposed patch so that sysinfo reverts back to its current behavior (that is: print the filename of the db2jcc_license_j jar file, and the version information from the DB2Driver which is in the classpath); my question is: is that really a useful behavior, or is there something more useful that we could print about the db2jcc_license_c.jar file specifically? > 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: 10.1.1.0 > Reporter: Bryan Pendleton > Priority: Minor > Attachments: Derby-668.diff, derby-668-2.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
