New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFCORE-4296][WFCORE-5406] Add required --add-opens for java.base/com.sun.net.ssl.internal.ssl when HTTPS is configured #4966
Conversation
Core - Full Integration Build 11374 outcome was FAILURE using a merge of 3e02eaf Failed tests
|
The warning on the illegal reflective access is gone, but there is going to be a new |
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ropalka Please update this file as well:
https://github.com/wildfly/wildfly-core/blob/main/bootable-jar/boot/pom.xml#L61
@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 wildfly-core/elytron/src/main/java/org/wildfly/extension/elytron/SSLDefinitions.java Line 1609 in a19937e
|
Fixed @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. |
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. |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
Is there any decision made on this ? |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
There has been no activity on this PR for 90 days and it has been closed automatically. |
reopen this since the WFCORE issue is still open. |
No @soul2zimate . The problem still persists - no possibility to detect exact running JVM version in shell scripts. |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
@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 |
Core -> WildFly Preview Integration Build 12795 outcome was FAILURE using a merge of 1914cd3 Failed tests
|
d559874
to
33624f8
Compare
@bstansberry please review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ropalka
I have a few comments; only substantial one is the timeout.
When this is ready please ping me in chat so I don't forget about it.
host-controller/src/main/java/org/jboss/as/host/controller/jvm/JvmType.java
Outdated
Show resolved
Hide resolved
host-controller/src/main/java/org/jboss/as/host/controller/jvm/JvmType.java
Show resolved
Hide resolved
launcher/src/main/java/org/wildfly/core/launcher/AbstractCommandBuilder.java
Outdated
Show resolved
Hide resolved
…internal.ssl when HTTPS is configured
…onditional because it is not available on all JDK versions
… method javadoc plus refactoring system property parsing
f980034
to
3b6b41f
Compare
Fixed @bstansberry . Thanks for review! |
@@ -164,7 +164,7 @@ | |||
NB: In case an update is made to these exports and opens, make sure that the common.sh script is in sync. | |||
--> | |||
<embedding.jar.jpms.exports>java.desktop/sun.awt java.naming/com.sun.jndi.ldap java.naming/com.sun.jndi.url.ldap java.naming/com.sun.jndi.url.ldaps jdk.naming.dns/com.sun.jndi.dns</embedding.jar.jpms.exports> | |||
<embedding.jar.jpms.opens>java.base/java.lang java.base/java.lang.invoke java.base/java.lang.reflect java.base/java.io java.base/java.net java.base/java.security java.base/java.util java.base/java.util.concurrent java.management/javax.management java.naming/javax.naming</embedding.jar.jpms.opens> | |||
<embedding.jar.jpms.opens>java.base/com.sun.net.ssl.internal.ssl java.base/java.lang java.base/java.lang.invoke java.base/java.lang.reflect java.base/java.io java.base/java.net java.base/java.security java.base/java.util java.base/java.util.concurrent java.management/javax.management java.naming/javax.naming</embedding.jar.jpms.opens> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ropalka @jfdenise AIUI this will result in a warning if the CLI or a bootable jar is used on SE 17. So in this case it seems we are forced to make a choice, unless there's some fancy MANIFEST.mf, etc thing in SE that allows some kind of conditional behavior.
If not, my inclination is to not add this since
-
Getting the warn with SE 11 is the existing state, whereas introducing a warn for SE 17 would be a breaking change. All things equal, annoying a fresh set of users in order to stop annoying ones who may already be used to the warn seems a bad tradeoff.
-
We'll be moving on from SE 11 soon enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unless there's some fancy MANIFEST.mf, etc thing in SE that allows some kind of conditional behavior.
there isn't anything conditional, but when MANIFEST.MF has add-opens/add-exports on non-existing module, it silently ignores it, so IIUC this could be fine then.
https://openjdk.org/jeps/261#Breaking-encapsulation
Two new JDK-specific JAR-file manifest attributes are defined to correspond to the --add-exports and --add-opens command-line options:
Add-Exports: <module>/<package>( <module>/<package>)*
Add-Opens: <module>/<package>( <module>/<package>)*
The value of each attribute is a space-separated list of slash-separated
module-name/package-name pairs.
A <module>/<package> pair in the value of an Add-Exports attribute has the same meaning
as the command-line option --add-exports <module>/<package>=ALL-UNNAMED.
A <module>/<package> pair in the value of an Add-Opens attribute has the same meaning
as the command-line option --add-opens <module>/<package>=ALL-UNNAMED.
Each attribute can occur at most once, in the main section of a MANIFEST.MF file.
A particular pair can be listed more than once.
If a specified module was not resolved, or if a specified package does not exist,
then the corresponding pair is ignored.
These attributes are interpreted only in the main executable JAR file of an application,
i.e., in the JAR file specified to the -jar option of the Java run-time launcher;
they are ignored in all other JAR files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, a lot @jbliznak -- that's very helpful.
@jbliznak is right. Not existenting values of add-opens or add-exports attributes in MANIFEST.MF are silently ignored for executable jar files. |
Thanks for review and merge of this PR @bstansberry |
I provided a reproducer (for the claim about executable jars) and attached it to the JIRA @bstansberry |
https://issues.redhat.com/browse/WFCORE-4296
https://issues.redhat.com/browse/WFCORE-5406
This PR follows up on:
This PR replaces: