db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1125) Getting security exception because classes in iapi.services.info have been added to derbyclient.jar
Date Fri, 17 Mar 2006 23:15:21 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1125?page=comments#action_12370904 ] 

David Van Couvering commented on DERBY-1125:
--------------------------------------------

OK, to be clear, what happened was not that I included the iapi/services/info package, that
has been there for a while.

What happened was I *copied* JVMInfo from iapi/services/info to shared/common/info.  At that
time I was unaware that iapi/services/info was being included in derbyclient.jar.

Then Knut discovered that JVMInfo was in two places in derbyclient.jar (iapi/services/info
and shared/common/info), so I then excluded services/info/JVMInfo.class from the derbyclient
jar file.  Case solved (hah!).

So now what happens is that services/info/JVMInfo is loaded from derby.jar when you run with
derby.jar and derbyclient.jar in the same classpath.  And then if you have derbyclient.jar
in from of derby.jar all other classes from the package services/info are loaded from derbyclient.jar.
 This is not allowed for sealed packages, thus the security exception.

I made my copy of JVMInfo because I had assumed it was a Bad Thing to copy the same classes
into two separate jar files.  This is called Code Sharing and is Not Allowed.  But it's been
there for quite a while. So in a mixed version environment you can have the same shadowing/compatibility
issues that have been painstakingly documented for code sharing in general.

So, we have the following choices:

(1)  I can remove the copy of JVMInfo in shared/common/info, and go back to the way things
were.  In my client code I can import org.apache.derby.iapi.services.info.JVMInfo instead
of org.apache.derby.shared.common.info.JVMInfo.    This is the way things were and would probably
be the simplest solution, but we would continue to have the potential issues around compatibility
and shadowing in a mixed version environment.  It is worth noting that this has not come up
as an issue as of yet.

(2) I can copy everything into org.apache.derby.shared.common and fix all client code so it
refers to the shared versions of this stuff.  The risk of this is now we have a fair amount
of code duplication, and things can get skewed pretty easily

(3) I can implement the proposal we had earlier, which was to use a build script to automatically
make a copy of the classes in iapi/services/info and put them in shared.  The engine code
would continue to use iapi/services/info, and the client code would use shared/common/info.
 I do have to wonder what is going on with the tools and network jar files, however, as I
think they are also making use of iapi/services/info classes.  This could turn into a Big
Project if I have to make copies for each jar file.

(4) Unseal iapi/services/info.  This seems like the wrong way to go.  This is an internal
package and we don't want it to be possible to interject "new" implementations of these classes
from other code bases.

My current itch is to put things back the way they were, and solve the longer-term code sharing
problem as part of the code sharing JIRA, DERBY-289.  So I am going to go with option (1).
 But please let me know if you have an opinion on this.

> Getting security exception because classes in iapi.services.info have been added to derbyclient.jar
> ---------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1125
>          URL: http://issues.apache.org/jira/browse/DERBY-1125
>      Project: Derby
>         Type: Bug
>     Reporter: David Van Couvering
>     Assignee: David Van Couvering

>
> From Andrew's email:
> On 3/17/06, Andreas Korneliussen <Andreas.Korneliussen@sun.com> wrote:
> > </snip a whole bunch of stuff>
> >
> > Exception: java.lang.SecurityException: sealing violation: can't seal package org.apache.derby.iapi.services.info:
> already loaded
> See DERBY-848 and DERBY-1046.
> iapi.services.info.ProductVersionHolder and friends were added to
> derbyclient.jar by David in DERBY-848, specifically with revision
> 370815.
> There are two clear solutions: unseal iapi.services.info or copy the
> info classes to a new shared info package.

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


Mime
View raw message