[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
-------------------------------
Description:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages. (See
https://issues.apache.org/jira/browse/GEODE-10128)
# Query the {{--add-opens}} and {{--add-exports}} that were used to launch the
current JVM. This can be done by calling
{{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
was:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages.
# Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
the current JVM. This can be done by calling
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
> Forward module-related options when launching test subprocesses
> ---------------------------------------------------------------
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
> Affects Versions: 1.16.0
> Reporter: Dale Emery
> Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
