Thanks, Kevin. When your fix turns up in a JDK release, I'll test drive
it. Then I may be able to back out the changes which I made to the Derby
tests and docs.
On 1/10/23 6:20 AM, Kevin Walls wrote:
Hi, that's great!
Maybe the remoteDeserializationEnabled() method is no longer needed? (
derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java )
Actually hold that thought while I tell you why I just logged a new JDK bug...
The JDK Core Libraries guide has more detail on Serialization Filters. There
is logging to show exactly what is rejected.
https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-6A048F49-052E-4591-9183-2775DC50831E
If I edit the jdk/conf/logging.properties file and uncomment the line:
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
and add:
java.io.serialization.level = FINE
..then I get a ~/java0.log in the home directory after the test. The failing
class is:
<message>ObjectInputFilter REJECTED: class javax.management.Attribute, array
length: -1, nRefs: 1, depth: 1, bytes: 102, ex: n/a</message>
Adding javax.management.Attribute to the list in management.properties works.
I'm thinking this should be in the list by default: the filter is intended to
need customisation for non-standard classes, but the basics should work
automatically.
The Derby test is calling: setAttribute(name, "CollectAccessCounts",
Boolean.TRUE);
...so not trying to transfer any of its own types across the connection, so
this probably is a bug in the filter value. If the parameters included
Derby-specific classes, you would expect to fail with the default filter and
need customisation.
Will follow this up in the JDK bug: https://bugs.openjdk.org/browse/JDK-8299891
Thanks!
Kevin
-----Original Message-----
From: Rick Hillegas <rick.hille...@gmail.com>
Sent: 09 January 2023 21:19
To: Kevin Walls <kevin.wa...@oracle.com>; derby-dev@db.apache.org
Cc: David Delabassee <david.delabas...@oracle.com>
Subject: Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds
Thanks for running that experiment, Kevin. I have reproduced your results,
re-enabled the skipped MBean tests, and documented this on
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7149__;!!ACWV5N9M2RV99hQ!JMEmA854HVODhgZXeDIVPYms8W096aLG-_TDeYhrp08mYMdNU38xKiOHS4f_Nl1SUz8x4UtmWOlqeW6LVkEpqR5Z$
.
While I have your attention, what should developers do when they see a
"java.io.InvalidClassException: filter status: REJECTED" error? Is there a way
to tease out which classes are failing deserialization so that the filter can be tailored
exactly? It would be nice to give users a workaround more subtle than turning off the
deserialization filter completely.
Thanks,
-Rick
On 1/6/23 3:59 PM, Kevin Walls wrote:
Hi Rick,
A little more on this MBean test situation. I think it was just that the
database itself was not running with the updated filter property setting.
I could reproduce the failure with:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBe
anTest
I could see that passing -D to the test app to relax the filter, does not pass
the -D to the spawned database process.
I can't see a way to do that with a setting, maybe there is a property
somewhere, but to test it I added a parameter in the method that sets up the
command line for MBean tests:
"../java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java"
124 protected static String[] getCommandLineProperties(boolean
authentication)
125 {
126 ArrayList<String> list = new ArrayList<String>();
127 list.add("com.sun.management.jmxremote.serial.filter.pattern=");
...etc...
...and rebuilding, I no longer see a failure.
Hopefully this, or something similar, can be used. There is no harm in
setting the filter pattern in earlier JDKs, where it defaults to being blank.
It would be great to update the recent edit about there being no way to set
this property, as that seems misleading. Apologies I didn't get here quick
enough to avoid that edit!
Thanks,
Kevin
From: Kevin Walls
Sent: 05 January 2023 13:54
To: rick.hille...@gmail.com
Cc: derby-dev@db.apache.org
Subject: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds
Hi Rick,
David pointed me at this thread about the ObjectInputFilter and Derby. I see
the notes on the use of -D to set a filter to run the test, but am unsure how
the database itself is started. That is in another process? (I think it's on
the same system, because you had success when changing the management
properties file.) How do we ensure that process is started with the same
arguments/filter pattern? (That is the process where we need the filter either
relaxed, or made more specific).
Thanks
Kevin
