[ 
http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12358985 ] 

Andrew McIntyre commented on DERBY-668:
---------------------------------------

Hi Bryan,

I took a look at version 3 of your patch. It looks good, just a couple comments:

- On Windows you get a leading slash before the drive spec (i.e. 
/C:/mydir/jars/...).  Might be worth fixing, but it is just a 'polish' issue.
- In test case 9 above, db2jcc_license_c.jar shows up in the output, but 
db2jcc.jar does not. It does appear as found in testcase 10. This behavior is 
the same as the current sysinfo. It would be nice if this were fixed, but this 
could be treated as a separate issue.
- My opinion is that it would be nice to have db2jcc_license_c.jar appear in 
the output if db2jcc.jar is not present. That can also be fixed as a separate 
issue, though.

I also stumbled across some really bizarre behavior (already present - not 
introduced by your patch), if you put derby.jar or one of the other product 
jars into the extensions directory, while there are others on the classpath. To 
see what I mean, try putting just derbynet.jar in the extensions, or putting 
derby.jar into the extensions dir while you have another on your classpath.

> 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, 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] 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

Reply via email to