[JBoss JIRA] (WFLY-11603) Intermittent NPE from MP config SubsystemDeploymentProcessor
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-11603?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-11603:
------------------------------------
[~jmesnil], thanks for the fix. I've just realized that part of the fix is change where you switch to deprecated class instead of the non-deprecated, [here|https://github.com/wildfly/wildfly/pull/12012/files#diff-6de66bee9c4...]. Is this intentional?
> Intermittent NPE from MP config SubsystemDeploymentProcessor
> ------------------------------------------------------------
>
> Key: WFLY-11603
> URL: https://issues.jboss.org/browse/WFLY-11603
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 15.0.1.Final
> Environment: Windows
> JDK-11
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
> In our automation tests, we can see intermittent NPE with following stack trace:
> {code}
> 20:01:38,985 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@54fd99c3 unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war": java.lang.NullPointerException
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:149)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 20:01:38,986 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.api@1.3.0.redhat-00001//org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.deploy(SubsystemDeploymentProcessor.java:67)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> ... 8 more
> {code}
> further on, there is also following error in the server.log (it has been dealt in WFWIP-64, although in different circumstances, I guess):
> {code}
> 20:01:39,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\".POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\"
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 20:01:39,169 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war" (runtime-name : "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")
> 20:01:39,171 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> {code}
> The NPE itself goes from the 'undeploy' method in SubsystemDeploymentProcessor. Although, according to the surrounding log messages (longer test log is attached [^NPE-server.log]), the server is still in the boot process by that time.
> This NPE happens quite rarely so it looks like some kind of a race-condition is in place. So far we have seen this only on Windows with JDK-11 combination but cannot say it does not affect other platforms for sure.
> Also, we have not seen it with latest WildFly nightly builds too (WildFly revision 353b95ef201c18dbd465087f520392c8525a2213) (yet?).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-9780) Minimize module dependencies
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-9780?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-9780.
------------------------------------
Fix Version/s: 16.0.0.Beta1
Assignee: Brian Stansberry
Resolution: Partially Completed
I'm going to resolve this as partially completed. We've been doing a lot of this the last six months (particularly [~yersan]) as part of the galleon layers work and I expect that will continue. But that work has been done on a case by case basis as we look at areas, and I expect it will continue that way.
> Minimize module dependencies
> ----------------------------
>
> Key: WFLY-9780
> URL: https://issues.jboss.org/browse/WFLY-9780
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4296) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4296?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-11123 to WFCORE-4296:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4296 (was: WFLY-11123)
Component/s: Security
(was: Security)
Affects Version/s: (was: 14.0.1.Final)
> Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
> -------------------------------------------------------------------------
>
> Key: WFCORE-4296
> URL: https://issues.jboss.org/browse/WFCORE-4296
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode)
> Reporter: Marco Del Percio
> Priority: Major
> Labels: Java11, access, elytron, illegal, reflective, wildfly
>
> After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron:
> {color:red}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS()
> WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {color}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4293) Command embed-server unrecognized arguments --jboss-home but in help it still a valid argument
by Vratislav Marek (Jira)
[ https://issues.jboss.org/browse/WFCORE-4293?page=com.atlassian.jira.plugi... ]
Vratislav Marek deleted WFCORE-4293:
------------------------------------
> Command embed-server unrecognized arguments --jboss-home but in help it still a valid argument
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-4293
> URL: https://issues.jboss.org/browse/WFCORE-4293
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Vratislav Marek
> Assignee: Jean-Francois Denise
> Priority: Major
>
> Command "_embed-server_" unrecognize argument "_--jboss-home_".
> {code:java}
> [disconnected /] embed-server --jboss-home=/tmp/2019-01-25/WFCORE-1187/firstLog
> Unrecognized arguments: [--jboss-home]
> {code}
> {code:java}
> [disconnected /] embed-server --jboss-home="/tmp/2019-01-25/WFCORE-1187/firstLog"
> Unrecognized arguments: [--jboss-home]
> {code}
> But in command help is written like a valid argument.
> {code:java}
> [disconnected /] help embed-server
> SYNOPSIS
> embed-server [--admin-only=true|false]
> [-c=config_file || --server-config=config_file]
> [--empty-config --remove-existing-config]
> [--jboss-home=rootdir]
> [--stdout=discard|echo]
> DESCRIPTION
> Launches a standalone server embedded in the CLI process.
> ARGUMENTS
> ...
> --jboss-home - Filesystem path pointing to the root directory
> of the installation from which the embedded server
> should run. Only available if the CLI itself
> is not running in a modular classloading environment.
> In a non-modular classloading environment, if this
> option is not specified, the value of the
> environment variable JBOSS_HOME will be used.
> Must be specified if the environment variable
> JBOSS_HOME is not set.In a modular classloading
> environment it is assumed the CLI is running from
> the server installation itself and the JBOSS_HOME
> environment variable must be set.
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11650) NPE with wildfly-openssl using OpenSSL 1.1.1a
by Jan Stourac (Jira)
Jan Stourac created WFLY-11650:
----------------------------------
Summary: NPE with wildfly-openssl using OpenSSL 1.1.1a
Key: WFLY-11650
URL: https://issues.jboss.org/browse/WFLY-11650
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 15.0.1.Final
Environment: OpenSSL 1.1.1a
Reporter: Jan Stourac
Assignee: Stuart Douglas
It is impossible to use {{wildfly-openssl}} binding with OpenSSL 1.1.1a (RHEL8 uses 1.1.1 at the moment but there seems to be same issue). There is an NPE during the ciphersuites initialization:
{code}
9:10:58,330 WARNING [org.wildfly.openssl.OpenSSLContextSPI] (MSC service thread 1-3) WFOPENSSL0014 Failed to initialize ciphers: java.lang.NullPointerException
at org.wildfly.openssl.CipherSuiteConverter.toJava(CipherSuiteConverter.java:284)
at org.wildfly.openssl.OpenSSLContextSPI.getAvailableCipherSuites(OpenSSLContextSPI.java:109)
at org.wildfly.openssl.OpenSSLEngine.getSupportedCipherSuites(OpenSSLEngine.java:711)
at org.wildfly.openssl.OpenSSLSocket.getSupportedCipherSuites(OpenSSLSocket.java:163)
at javax.net.ssl.SSLContextSpi.engineGetSupportedSSLParameters(SSLContextSpi.java:194)
at javax.net.ssl.SSLContext.getSupportedSSLParameters(SSLContext.java:436)
at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:116)
at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
and then there is NPE during the request itself:
{code}
19:12:18,417 ERROR [org.xnio.listener] (default I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
at org.wildfly.openssl.CipherSuiteConverter.toJava(CipherSuiteConverter.java:284)
at org.wildfly.openssl.OpenSSLEngine.toJavaCipherSuite(OpenSSLEngine.java:1094)
at org.wildfly.openssl.OpenSSLEngine.getEnabledCipherSuites(OpenSSLEngine.java:729)
at org.wildfly.openssl.OpenSSLContextSPI.getCiphers(OpenSSLContextSPI.java:339)
at org.wildfly.openssl.OpenSSLEngine.getEnabledCipherSuites(OpenSSLEngine.java:720)
at io.undertow.server.protocol.http.AlpnOpenListener.engineSupportsHTTP2(AlpnOpenListener.java:324)
at io.undertow.server.protocol.http.AlpnOpenListener$1.apply(AlpnOpenListener.java:239)
at io.undertow.server.protocol.http.AlpnOpenListener$1.apply(AlpnOpenListener.java:235)
at io.undertow.server.protocol.http.AlpnOpenListener$SSLConduitUpdater.apply(AlpnOpenListener.java:430)
at io.undertow.server.protocol.http.AlpnOpenListener$SSLConduitUpdater.apply(AlpnOpenListener.java:419)
at io.undertow.protocols.alpn.DefaultAlpnEngineManager.registerEngine(DefaultAlpnEngineManager.java:31)
at io.undertow.protocols.alpn.ALPNManager.registerEngineCallback(ALPNManager.java:80)
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:235)
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:64)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
{code}
Looking briefly into it, the cipher that is trying to be used is *{{TLS_AES_256_GCM_SHA384}}*. It is interesting that this cipher has underscores '_' in its name instead of hyphens '-' as most of the openssl ciphers have. Looks like these were added in the sake of TLSv1.3, [see here|https://github.com/openssl/openssl/commit/fa25763b5528b56b448d64bfba...].
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months