wildfly
[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module
Supersedes https://github.com/wildfly/wildfly-core/pull/5947
Jira issue: https://issues.redhat.com/browse/WFCORE-6755
See https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/Layers.20and.20optional.20packages.
This PR includes #5947 but removes the community stability property configuration from org.wildfly.security.elytron-dynamic-ssl JBoss Modules module and adds its package as required for the Elytron layer. Until getting a better approach for this case, this will fix the issue reported by the test case where this module was not provisioned when using Elytron Galleon Layer and ensure we can use default stability level out of the box when the server is built targetting this stability level.
Core -> Full Integration Build 13655 outcome was FAILURE using a merge of 1fc882964e634634d5615e99afcac16dd1695298 Summary: Tests passed: 169, ignored: 4; exit code 1 (Step: Test full with JDK 11 (Maven)) (new) Build time: 00:17:42
Hello @fjuma / @darranl , a friendly reminder that I requested any of you to review this one, thanks!
@fjuma / @darranl, sorry for the noise, forget my last comment, I have to review the current status first since I lost track of this one, I'm going to remove you from the review until this one gets refreshed
@yersan FYI I will be working on a PR to promote this to default soon, although would be good to know we could solve this situation if it comes up again so I think still worth proceeding for now.
@darranl I want to back to this once we have passed the feature freeze, I plan to take a closer look next week
@darranl kicked it off again, I've added valid-for-stability to the package dependency for Elytron layer, does mean, the package will not be provisioned for an stability level with higher stability than "community"
Core -> Full Integration Build 13962 outcome was FAILURE using a merge of fdd87e97e2b56c1c85d37c24a02178bd026bb82f Summary: Tests failed: 1 (1 new), passed: 4129, ignored: 43 Build time: 02:18:10
Failed tests
org.wildfly.test.integration.observability.micrometer.multiple.MultipleWarTestCase(layers-test).checkPingCount: java.lang.AssertionError: expected:<2> but was:<1>
at org.wildfly.test.integration.observability.micrometer.multiple.MultipleWarTestCase.checkPingCount(MultipleWarTestCase.java:54)
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)
at jdk.internal.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
------- Stdout: -------
[0m15:29:49,502 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: '/lra-participant-narayana-proxy' from server 'default-server'
[0m [0m15:29:49,503 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
[0m [0m15:29:49,504 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
[0m [0m15:29:49,505 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to [::1]:8080
[0m [0m15:29:49,505 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment arquillian-service (runtime-name: arquillian-service) in 4ms
[0m [0m15:29:49,505 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2
[0m [0m15:29:49,505 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: '/lra-coordinator' from server 'default-server'
[0m [33m15:29:49,509 WARNING [io.micrometer.registry.otlp.OtlpMeterRegistry] (otlp-metrics-publisher) Failed to publish metrics to OTLP receiver: java.net.ConnectException: Connection refused (Connection refused)
at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:412)
at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:255)
at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:237)
at java.base/java.net.Socket.connect(Socket.java:609)
at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:177)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:604)
at java.base/sun.net.www.http.HttpClient.<init>(HttpClient.java:277)
at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:376)
at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:397)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1253)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1187)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1081)
at java.base/sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:1015)
Core -> Full Integration Build 13963 outcome was FAILURE using a merge of fdd87e97e2b56c1c85d37c24a02178bd026bb82f Summary: Tests failed: 1 (1 new), passed: 3989, ignored: 59 Build time: 02:22:38
Failed tests
org.jboss.as.test.clustering.cluster.ejb.timer.DistributedTimerServiceTestCase.test: java.lang.AssertionError: class org.jboss.as.test.clustering.cluster.ejb.timer.beans.AutoPersistentTimerBean={node-1=[]}. Actual: 0
at org.jboss.as.test.clustering.cluster.ejb.timer.AbstractTimerServiceTestCase.test(AbstractTimerServiceTestCase.java:305)
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)
at jdk.internal.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
------- Stdout: -------
node-2 2024-10-01 18:53:03,433 INFO [org.jboss.modules] (main) JBoss Modules version 2.1.5.Final
node-2 2024-10-01 18:53:03,978 INFO [org.jboss.msc] (main) JBoss MSC version 1.5.5.Final
node-2 2024-10-01 18:53:03,987 INFO [org.jboss.threads] (main) JBoss Threads version 2.4.0.Final
node-2 2024-10-01 18:53:04,120 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly 34.0.0.Final-SNAPSHOT (WildFly Core 26.0.0.Beta6-SNAPSHOT) starting
node-2 2024-10-01 18:53:05,723 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 2.6.0.Final
node-2 2024-10-01 18:53:06,717 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
node-2 2024-10-01 18:53:06,734 INFO [org.xnio] (MSC service thread 1-3) XNIO version 3.8.16.Final
node-2 2024-10-01 18:53:06,744 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.8.16.Final
node-2 2024-10-01 18:53:06,794 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.29.Final
node-2 2024-10-01 18:53:06,843 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 40) WFLYCLINF0001: Activating Infinispan subsystem.
node-2 2024-10-01 18:53:06,839 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 42) WFLYRS0016: RESTEasy version 6.2.10.Final
node-2 2024-10-01 18:53:06,904 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 53) WFLYTX0013: The node-identifier attribute on the /subsystem=transactions is set to the default value. This is a danger for environments running multiple servers. Please make sure the attribute value is unique.
node-2 2024-10-01 18:53:06,938 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 41) WFLYIO001: Worker 'default' has auto-configured to 8 IO threads with 64 max task threads based on your 4 available processors
node-2 2024-10-01 18:53:06,998 INFO [org.jboss.as.connector] (MSC service thread 1-4) WFLYJCA0009: Starting Jakarta Connectors Subsystem (WildFly/IronJacamar 3.0.10.Final)
node-2 2024-10-01 18:53:07,030 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 44) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 5.2.28
node-2 2024-10-01 18:53:07,025 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0003: Undertow 2.3.17.Final starting
node-2 2024-10-01 18:53:07,060 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 48) WFLYNAM0001: Activating Naming Subsystem
node-2 2024-10-01 18:53:07,093 INFO [org.jboss.as.naming] (MSC service thread 1-5) WFLYNAM0003: Starting Naming Service
node-2 2024-10-01 18:53:07,063 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 32) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 2.2)
node-2 2024-10-01 18:53:07,226 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2
node-2 2024-10-01 18:53:07,269 WARN [org.wildfly.extension.elytron] (MSC service thread 1-3) WFLYELY00023: KeyStore file '/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/integration/clustering/target/wildfly-clustering-ejb-2/standalone/configuration/application.keystore' does not exist. Used blank.
node-2 2024-10-01 18:53:07,317 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 64 (per class), which is derived from thread worker pool sizing.
node-2 2024-10-01 18:53:07,331 INFO [org.jboss.as.ejb3] (MSC service thread 1-5) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 16 (per class), which is derived from the number of CPUs on this host.
@darranl friendly reminder, when you have a chance, take a look at this one and approve from your side, thanks!
@yersan we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.
we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.
@darranl the valid-for-stability to the package dependency on Elytron layer does that
we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.
Also, "lower stability", I assume you are talking about higher stability levels (e.g default)
@darranl ok, and then, since we are using valid-for-stability, would you agree to resolve this as it is now?
@yersan What we need is a generic solution so that the module is correctly provisioned at the various stability levels and not provisioned when we only support default - do we have that today?
@darranl yes, we are using the "valid-for-stability" attribute at a package level to decide when we want this packaged provisioned, so we are not provisioning it for any stability level higher than community. At conversion time branches we can add a simple maven verify configuration to verify this module is not provisioned so we be more confident about this. I can add that after merging this and rebasing the conversion.
@darranl
so both commits on this PR complete that?
One commit picked up the work done by @Skyllarr (this Supersedes https://github.com/wildfly/wildfly-core/pull/5947) which separates the Elytron dynamic SSL package from Elytron in a separate JBoss Modules module and Galleon package. We had issues with that change because we were not able at that time to provision the separated package/module only in the required stability levels (community and below, even using JBoss Modules <property name="jboss.stability" value="community"/> property name)
The second commit I added to that PR does it. We are now using the valid-for-stability configuration at package level.
If we want to be more confident with these changes, we can use the maven verify plugin and assert this package is not provisioned when we are building to "default" stability level using the conversion branches. This change is not in this PR it is a proposed change to be included via conversion branches.
@darranl just a friendly remainder about this, I would like to release it the sooner the better since it affects the conversion branches, indeed we are already using it there, so if you need to do any manual verification to approve this, you can use the conversion branches
@darranl Do you have any questions regarding this PR? Do you plan to review it?