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://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 list = new ArrayList();
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
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656291#comment-17656291 ] ASF subversion and git services commented on DERBY-7149: Commit 1906522 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906522 ] DERBY-7149: Re-enable skipped MBean tests; commit derby-7149-05-aa-reenableJMXTest.diff. > 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, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656289#comment-17656289
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-05-aa-reenableJMXTest.diff. This patch re-enables the
skipped MBean tests and sets the following property on the remote JVM so that
the tests run again:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=
{noformat}
Full tests ran cleanly for me with the classpath. Based on that evidence, I
didn't bother running the tests with the modulepath.
Touches the following files:
{noformat}
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java
{noformat}
> 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,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar,
> derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff,
> derby-7149-05-aa-reenableJMXTest.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-05-aa-reenableJMXTest.diff > 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, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656287#comment-17656287
]
Richard N. Hillegas commented on DERBY-7149:
In a private email, Kevin Walls from the Open JDK team reported that he was
able to get CacheManagerMBeanTest to run by setting the following system
property on the remote process:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=
{noformat}
I don't know why this didn't work for me. Maybe my experiments were setting the
property on the wrong JVM.
> 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,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar,
> derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
