[
https://issues.apache.org/jira/browse/DERBY-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413816#comment-13413816
]
Knut Anders Hatlen commented on DERBY-5840:
-------------------------------------------
I found that I got a sealing violation error when I tried to start the network
server with "java -jar derbynet.jar start" after applying the 03-aa patch:
$ java -jar derbynet.jar start
Fri Jul 13 16:12:58 CEST 2012 : Security manager installed using the Basic
server security policy.
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1008)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:711)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2226)
at
org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:352)
Caused by: java.lang.SecurityException: sealing violation: package
org.apache.derby.mbeans is sealed
at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:388)
(...)
The JUnit tests would fail for similar reasons if derbynet.jar appeared before
derby.jar on the classpath.
The reason was that org.apache.derby.mbeans.VersionMBean ended up both in
derby.jar and derbynet.jar, and it should only be in derby.jar.
NetworkServerControlImpl has a reference to VersionMBean.class, and so it did
before the patch:
final Object versionMBean = mgmtService.registerMBean(
new Version(
getNetProductVersionHolder(),
SystemPermission.SERVER),
VersionMBean.class,
"type=Version,jar=derbynet.jar");
When I disassembled the old and the new version of the NetworkServerControlImpl
class, I found that the old version, compiled with target level 1.4, had no
reference to VersionMBean.class, only to the string
"org.apache.derby.mbeans.VersionMBean". The byte code would dynamically load
the class when the code that referenced it was invoked. Since there's no
reference to the class, classlister couldn't find it. When compiled with target
level 1.5, on the other hand, the byte code would have a direct reference to
the class instance, and that enables classlister to find the dependency.
I think the fix is to make classlister ignore the org.apache.derby.mbeans
package when building the list of classes to include in derbynet.jar. It
already has a list of other engine packages to exclude, so we could add the
package to that list.
> Clean up compiler warnings introduced by using Java 5 language features
> -----------------------------------------------------------------------
>
> Key: DERBY-5840
> URL: https://issues.apache.org/jira/browse/DERBY-5840
> Project: Derby
> Issue Type: Improvement
> Components: Miscellaneous
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Attachments: derby-5840-01-aa-compatibilityTests.diff,
> derby-5840-02-aa-compatibilityTests-again.diff.txt, derby-5840-03-aa-drda.diff
>
>
> Using Java 5 language features forces us to compile code at level 5 or
> higher. At this level, the compiler raises warnings not seen at lower levels.
> This issue is a place to discuss and attach cleanup to eliminate these
> warnings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
