Thanks for running that experiment, Kevin. I have reproduced your
results, re-enabled the skipped MBean tests, and documented this on
https://issues.apache.org/jira/browse/DERBY-7149.
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.CacheManagerMBeanTest
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
