[jira] Updated: (DERBY-826) sysinfo does not report the version of derby.jar if the class does not explictly contain it.

["Andrew McIntyre (JIRA)" <de...@db.apache.org>]

     [ http://issues.apache.org/jira/browse/DERBY-826?page=all ]

Andrew McIntyre updated DERBY-826:
----------------------------------

    Attachment: derby-826.diff

This patch attempts to locate the info properties files using getResource() first, and then through the classpath. This allows us to find the info properties files when loaded from mechanisms other than through the classpath, e.g. from the extensions directory, java -jar, the Class-Path attribute, etc. Also added javadoc for the methods that I touched.

Related to DERBY-668, this fixes the regular (non -cp) part of that issue.

I will commit this early next week if there are no concerns.

> sysinfo does not report the version of derby.jar if the class does not explictly contain it.
> --------------------------------------------------------------------------------------------
>
>          Key: DERBY-826
>          URL: http://issues.apache.org/jira/browse/DERBY-826
>      Project: Derby
>         Type: Bug

>   Components: Tools
>     Versions: 10.2.0.0
>     Reporter: Daniel John Debrunner
>     Assignee: Andrew McIntyre
>     Priority: Minor
>  Attachments: derby-826.diff
>
> derby.jar is in the classpath here indirectly because derbynet.jar includes it through a manifest entry.
> java -cp jars/sane/derbynet.jar org.apache.derby.tools.sysinfo
> ------------------ Java Information ------------------
> Java Version:    1.4.2
> Java Vendor:     IBM Corporation
> Java home:       C:\Program Files\IBM\Java142\jre
> Java classpath:  jars/sane/derbynet.jar
> OS name:         Windows XP
> OS architecture: x86
> OS version:      5.1
> Java user name:  djd
> Java user home:  C:\Documents and Settings\Administrator
> Java user dir:   c:\_work\svn_clean2\trunk
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> --------- Derby Information --------
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\_work\svn_clean2\trunk\jars\sane\derbynet.jar] 10.2.0.0 alpha - (370500M)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale :  [English/United States [en_US]]
> Found support for locale: [de_DE]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [es]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [fr]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [it]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [ja_JP]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [ko_KR]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [pt_BR]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [zh_CN]
>          version: 10.2.0.0 alpha - (370500M)
> Found support for locale: [zh_TW]
>          version: 10.2.0.0 alpha - (370500M)
> ------------------------------------------------------

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

Re: [jira] Updated: (DERBY-826) sysinfo does not report the version of derby.jar if the class does not explictly contain it.

[Bryan Pendleton <bp...@amberpoint.com>]

>      [ http://issues.apache.org/jira/browse/DERBY-826?page=all ]
> 
> Andrew McIntyre updated DERBY-826:

Andrew, thank you *so* much for adding those comments! I wish they
had been in place when I was starting to read that code.

I successfully applied your patch and confirmed your results, and
they look good to me. Here are a few comments that you might
want to consider:

1) At around line 1123 of the new Main.java, you introduced a new
variable "InputStream is = null;" for no reason that I can see.
Perhaps this new variable is unnecessary?

2) When I run your particular test case (java -cp derbynet.jar sysinfo)
with the new code, the result is a little bit confusing because
derbynet.jar now appears twice. The output looks like:

--------- Derby Information --------
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[C:/bryan/src/derby/main/trunk/jars/sane/derby.jar] 10.2.0.0 alpha - (392542M)
[C:/bryan/src/derby/main/trunk/jars/sane/derbynet.jar] 10.2.0.0 alpha - (392542M)
[C:\bryan\src\derby\main\trunk\jars\sane\derbynet.jar] 10.2.0.0 alpha - (392542M)

Does this duplication of output have something to do with the direction
of the slashes in the file names? Do you understand why I got this
behavior?

3) Stylistically, I wonder if it would be clearer to take the code
which cleans up an URL for presentation, starting at around line 811
in the new file, and break that code out into a subroutine. That way,
the overall flow of loadZipFromResource(), which is an important
routine for understanding sysinfo, would be easier to follow.

4) It would be nice to beef up the comments for mergeZips slightly,
as I found myself asking two questions when I was first reading it:
   - First, I didn't understand why there would be duplicates in the
     arrays, so it might be nice to provide some comments explaining
     why duplicate entries in the arrays might occur
   - Second, I didn't understand why the second array might be null, and
     I got a little bit thrown by the concept of "merging" an array with
     a null array. But then I realized that the mergeZips routine *also*
     can be called just to compress duplicates out of a single array.

Again, thanks very much for all the clear code and great comments in
your patch.

thanks,

bryan