[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17654117#comment-17654117 ]
Richard N. Hillegas commented on DERBY-7149: -------------------------------------------- The breakage in CacheManagerMBeanTest is caused by a security enhancement in the JVM. RMI-initiated deserialization has been locked down. A new filter must be relaxed in order to deserialize information exposed by our MBeans, when running the beans remotely over RMI. The filter is declared by the following Oracle-specific property in $JAVA_HOME/conf/management/management.properties: {noformat} com.sun.management.jmxremote.serial.filter.pattern {noformat} Open JDK build 20-ea+27-2213 sets this property as follows: {noformat} com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!* {noformat} The filter cannot be overridden on the boot command line via a system property. The filter can only be relaxed by hacking the JVM, that is, by editing $JAVA_HOME/conf/management/management.properties. But this filter must be relaxed in order to use our MBeans over RMI in order to examine the page and statement caches. The following brute-force, bulk relaxation works: {noformat} com.sun.management.jmxremote.serial.filter.pattern=* {noformat} I have not dug further into this to discover whether our MBeans would work with a narrower filter, tailored to a few specific classes. Our MBeans are not particularly useful and I don't think many applications use them. I regard our MBeans as a proof of concept which someone could build on. No-one has done so. I do not see much value in investing more work in a rarely used feature which is becoming harder to use. The following links explain something about this JVM behavior change: https://bugs.openjdk.org/browse/JDK-8283093 https://bugs.openjdk.org/browse/JDK-8295938 I intend to modify CacheManagerMBeanTest so that it skips the failing tests when the default, restrictive filter is in place. I think it would also be a good idea to modify our MBean documentation to describe this problem and its workaround. > Make it possible to build and test Derby cleanly with JDK 20 > ------------------------------------------------------------ > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools > Affects Versions: 10.17.0.0 > Reporter: Richard N. Hillegas > Assignee: Richard N. Hillegas > Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)