db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-668) SysInfo can give misleading information when JDBC jars are loaded from jre/lib/ext
Date Fri, 02 Dec 2005 18:04:08 GMT
My experience has been this works with classes in the classes directory 
but not in jar files.  I am using the privileged action

Class.getProtectionDomain().getCodesource()

and it works well.  It does need to be run in a privileged block and you 
need to give permissions to the jar file using it.  An example of this 
is coming with my patch, and I was going to propose modifying Bryan's 
work to use the utility routine I've written for just this purpose.

David

Daniel John Debrunner (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12359101 ]

> 
> Daniel John Debrunner commented on DERBY-668:
> ---------------------------------------------
> 
> Is this code used?
> 
> 
> +    // Given a loaded class, and the name by which we loaded that class, this
> +    // routine asks the class's class loader for information about where the
> +    // class was loaded from. Typically, this is a file, which might be
> +    // either a class file or a jar file. The routine figures that out, and
> +    // returns the name of the file. If it can't figure it out, it returns null
> +    private static String getFileWhichLoadedClass(Class c, String cName)
> +    {
> +        String className = "/" + cName.replace('.', '/') + ".class";
> +        java.net.URL url = c.getResource(className);
> 
> because I thought a class loader was not allowed to return the .class file as a resource
for security reasons.
> 
> 
> 
>>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.
> 
> 

Mime
View raw message