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

Kathey Marsden commented on DERBY-668:
--------------------------------------

There is no special version information for the license file or documentation 
for the DB2J class. It has never really changed from release to release so 
version information is not really relevant.    It is very important that it be 
listed in sysinfo because I would say its absence is the #1 reported reason JCC 
doesn't work.  It's mere existance seems to be the key.

As long as it prints the filename it is fine  for it to print the DB2Driver 
version or even no version at IMO


> 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

Reply via email to