[ 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 <[EMAIL PROTECTED]> 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
