[WFCORE-4296][WFCORE-5406] Add required --add-opens for java.base/com.sun.net.ssl.internal.ssl when HTTPS is configured

[ropalka]

https://issues.redhat.com/browse/WFCORE-4296 https://issues.redhat.com/browse/WFCORE-5406

This PR follows up on:

• https://github.com/wildfly/wildfly-core/pull/4728
• https://github.com/wildfly/wildfly-core/pull/4728

This PR replaces:

• https://github.com/wildfly/wildfly/pull/15208

[wildfly-ci]

Core - Full Integration Build 11374 outcome was FAILURE using a merge of 3e02eafbcf45477e2e8e5e8f000a9ca45bedb35e Summary: Tests failed: 1 (1 new), passed: 7165, ignored: 144 Build time: 03:33:57

Failed tests

org.wildfly.extension.undertow.ServerServiceTestCase.testDefinedAttributes: java.lang.AssertionError: expected:<1> but was:<0>
	at org.wildfly.extension.undertow.ServerServiceTestCase.testDefinedAttributes(ServerServiceTestCase.java:141)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[soul2zimate]

The warning on the illegal reflective access is gone, but there is going to be a new WARNING: package com.sun.net.ssl.internal.ssl not in java.base with Java 13 or later (server boot up and jboss-cli.sh launching), Because the internal package com.sun.net.ssl has been removed since Java 13 (https://bugs.openjdk.java.net/browse/JDK-8215430). Is that OK ?

[ropalka]

This is interesting problem @bstansberry . Package to be opened exists on JDK11 but doesn't exist on JDK17. I think JDK17 represent higher priority than JDK11, doesn't it? I am thinking whether to not drop this PR. WDYT?

[fjuma]

@ropalka Just FYI, when that method doesn't exist, a different approach is used to detect if FIPS is enabled, see:

https://issues.redhat.com/browse/WFCORE-5566

and

https://github.com/wildfly/wildfly-core/blob/a19937eea5a4a51cd3a51cb0a034716c17f87944/elytron/src/main/java/org/wildfly/extension/elytron/SSLDefinitions.java#L1609

[ropalka]

@ropalka Please update this file as well:

https://github.com/wildfly/wildfly-core/blob/main/bootable-jar/boot/pom.xml#L61

Fixed @bstansberry

[bstansberry]

@ropalka Good question, and thank you @soul2zimate for raising the point. I agree that SE 17 should get higher priority. JPMS warns in SE 11 are partly (mostly?) meant to guide people toward the right code for later releases when JPMS would be more strict. And we've been guided -- WFCORE-5566 is evidence of that.

But please leave this open as it's a good place to discuss the tradeoffs.

[ropalka]

But please leave this open as it's a good place to discuss the tradeoffs.

The main problem is there is currently not available any way to detect the JVM version we are running on. Neither in shell scripts nor in Java source code. This kind of problems would be nicely solvable if we would have such detection possibility.

[github-actions[bot]]

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

[soul2zimate]

Is there any decision made on this ?

[github-actions[bot]]

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

[github-actions[bot]]

There has been no activity on this PR for 90 days and it has been closed automatically.

[soul2zimate]

reopen this since the WFCORE issue is still open.

[ropalka]

Is there any decision made on this ?

No @soul2zimate . The problem still persists - no possibility to detect exact running JVM version in shell scripts.

[github-actions[bot]]

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

[jbliznak]

no possibility to detect exact running JVM version in shell scripts

@ropalka why do we need exact version?

Aother idea, can't we just use the exact same trick as here (simply try the problematic argument first and act accordingly later)? https://github.com/wildfly/wildfly-core/blob/main/core-feature-pack/common/src/main/resources/content/bin/common.sh#L27-L29

[gaol]

@ropalka does what @jbliznak's suggestion make sense to you ? and may I ask you to rebase ? Thanks :)

[wildfly-ci]

Core -> WildFly Preview Integration Build 12795 outcome was FAILURE using a merge of 1914cd3bc0a9408ac7250e7e0fa376ebfecd8e8d Summary: Tests failed: 1 (1 new), passed: 2651, ignored: 44 Build time: 01:52:25

Failed tests

org.wildfly.test.scripts.AppClientScriptTestCase.testBashScript: java.lang.AssertionError: Expected 2 lines.
Command Executed:
/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/scripts/target/wildfly/bin/appclient.sh -v
Environment:
Output:
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
[0m16:24:59,545 INFO  [org.jboss.modules] (main) JBoss Modules version 2.1.2.Final
[0mWildFly Core 22.0.0.Beta2-SNAPSHOT
 expected:<2> but was:<3>
java.lang.AssertionError: 
Expected 2 lines.
Command Executed:
/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/scripts/target/wildfly/bin/appclient.sh -v
Environment:
Output:
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
 [0m16:24:59,545 INFO  [org.jboss.modules] (main) JBoss Modules version 2.1.2.Final
 [0mWildFly Core 22.0.0.Beta2-SNAPSHOT
 expected:<2> but was:<3>
	at org.wildfly.test.scripts.AppClientScriptTestCase.testScript(AppClientScriptTestCase.java:52)
	at org.wildfly.test.scripts.ScriptTestCase.executeTests(ScriptTestCase.java:153)
	at org.wildfly.test.scripts.ScriptTestCase.testBashScript(ScriptTestCase.java:102)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[ropalka]

@bstansberry please review

[ropalka]

Fixed @bstansberry . Thanks for review!

[bstansberry]

Thanks @ropalka and @jbliznak

[ropalka]

@jbliznak is right. Not existenting values of add-opens or add-exports attributes in MANIFEST.MF are silently ignored for executable jar files.

[ropalka]

Thanks for review and merge of this PR @bstansberry

[ropalka]

I provided a reproducer (for the claim about executable jars) and attached it to the JIRA @bstansberry