Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <33469777.1132768416938.JavaMail.jira@ajax.apache.org>
Date: Wed, 23 Nov 2005 18:53:36 +0100 (CET)
From: "Bryan Pendleton (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-668) SysInfo can give misleading information
 when JDBC jars are loaded from jre/lib/ext
In-Reply-To: <1153567093.1130883415407.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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

Bryan Pendleton commented on DERBY-668:
---------------------------------------

Hi Kathey, thanks for the feedback.

I think we can make sysinfo do a variety of things; I was treading cautiously because I'm unsure of the requirements.

The current implementation in the reportCloudscape() and getAllInfo() methods is basically a "for each entry in the classpath, print some info about it", and so I was trying to fit into that implementation without perturbing it very much. Therefore, as you noticed, my change only affects the case where db2jcc.jar is in the classpath but the DB2Driver class turns out to get loaded from some other location. The code that I altered is triggered by finding db2jcc.jar in the classpath.

It would be possible to write an alternate implementation, such as the following:
 - Construct a list of "sentinel" classes, and the jar files that we expect such classes to be loaded from
 - For each sentinel class, load it, then look to see from which jar it was loaded.
 - Print the information about the jar, and decorate that message in a special way if the class was not loaded from the expected jar.

It sort of seems like that is the intent of the useMe() and tryAllClasspaths() methods, which appear to be run only if you pass the "-cp" argument to sysinfo (http://db.apache.org/derby/docs/10.1/tools/ctoolssysinfo1002931.html), which I admit I had overlooked.

I'll take a look at this part of sysinfo, and investigate how I could improve it, as well.


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