[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11601:
--------------------------------------
In rough shapes, what needs to be done it setting up an "optional" MSC dependency Undertow -> Weld.
It should look something like this (thanks to Richard for explanation, following is an excerpt from our conversation):
* either inspect WildFly DMR model or WildFly capabilities to see if Weld subsystem is available
* if answer is no then there will be no dependency configured
* if answer is yes then set up {{WeldStartCompletionService}} as a dependency of the {{UndertowDeploymentService}}
> Weld vs Undertow bootstrap: Race condition
> ------------------------------------------
>
> Key: WFLY-11601
> URL: https://issues.jboss.org/browse/WFLY-11601
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 15.0.1.Final
> Reporter: Ste Gr
> Assignee: Matej Novotny
> Priority: Major
> Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar
>
>
> WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
> You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
> In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
> A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11753) NPE with wildfly-openssl using OpenSSL 1.1.1a
by Jan Stourac (Jira)
Jan Stourac created WFLY-11753:
----------------------------------
Summary: NPE with wildfly-openssl using OpenSSL 1.1.1a
Key: WFLY-11753
URL: https://issues.jboss.org/browse/WFLY-11753
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, 2 months
[JBoss JIRA] (WFLY-11752) testsuite/integration/elytron uses directly a jboss.dist dir when set instead of its copy in the target dir
by Ondrej Kotek (Jira)
[ https://issues.jboss.org/browse/WFLY-11752?page=com.atlassian.jira.plugin... ]
Ondrej Kotek updated WFLY-11752:
--------------------------------
Description:
When the {{jboss.dist}} property is set for the {{mvn}} command, the {{testsuite/integration/elytron}} project uses directly a server distribution in the {{jboss.dist}} directory instead of its copy in the {{target/wildfly}} directory, and the distribution is customized with the {{modify-elytron-config.cli}} script.
As a result, when running the test suite in the elytron mode ({{-Delytron}}), the next testing module ({{compat}}) fails.
It also brings difficulties when developing tests in the elytron test module itself.
was:
The {{testsuite/integration/elytron}} project uses directly a server distribution in the {{jboss.dist}} directory instead of its copy in the {{target/wildfly}} directory. Hence the distribution is customized with the {{modify-elytron-config.cli}} script.
As a result, when running the test suite in the elytron mode ({{-Delytron}}), the next testing module ({{compat}}) fails.
It also brings difficulties when developing tests in the elytron test module itself.
> testsuite/integration/elytron uses directly a jboss.dist dir when set instead of its copy in the target dir
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11752
> URL: https://issues.jboss.org/browse/WFLY-11752
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 16.0.0.CR1
> Reporter: Ondrej Kotek
> Priority: Major
>
> When the {{jboss.dist}} property is set for the {{mvn}} command, the {{testsuite/integration/elytron}} project uses directly a server distribution in the {{jboss.dist}} directory instead of its copy in the {{target/wildfly}} directory, and the distribution is customized with the {{modify-elytron-config.cli}} script.
> As a result, when running the test suite in the elytron mode ({{-Delytron}}), the next testing module ({{compat}}) fails.
> It also brings difficulties when developing tests in the elytron test module itself.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11752) testsuite/integration/elytron uses directly a jboss.dist dir when set instead of its copy in the target dir
by Ondrej Kotek (Jira)
[ https://issues.jboss.org/browse/WFLY-11752?page=com.atlassian.jira.plugin... ]
Ondrej Kotek updated WFLY-11752:
--------------------------------
Summary: testsuite/integration/elytron uses directly a jboss.dist dir when set instead of its copy in the target dir (was: testsuite/integration/elytron uses directly a jboss.dist dir instead of its copy in the target dir)
> testsuite/integration/elytron uses directly a jboss.dist dir when set instead of its copy in the target dir
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11752
> URL: https://issues.jboss.org/browse/WFLY-11752
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 16.0.0.CR1
> Reporter: Ondrej Kotek
> Priority: Major
>
> The {{testsuite/integration/elytron}} project uses directly a server distribution in the {{jboss.dist}} directory instead of its copy in the {{target/wildfly}} directory. Hence the distribution is customized with the {{modify-elytron-config.cli}} script.
> As a result, when running the test suite in the elytron mode ({{-Delytron}}), the next testing module ({{compat}}) fails.
> It also brings difficulties when developing tests in the elytron test module itself.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11752) testsuite/integration/elytron uses directly a jboss.dist dir instead of its copy in the target dir
by Ondrej Kotek (Jira)
Ondrej Kotek created WFLY-11752:
-----------------------------------
Summary: testsuite/integration/elytron uses directly a jboss.dist dir instead of its copy in the target dir
Key: WFLY-11752
URL: https://issues.jboss.org/browse/WFLY-11752
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 16.0.0.CR1
Reporter: Ondrej Kotek
The {{testsuite/integration/elytron}} project uses directly a server distribution in the {{jboss.dist}} directory instead of its copy in the {{target/wildfly}} directory. Hence the distribution is customized with the {{modify-elytron-config.cli}} script.
As a result, when running the test suite in the elytron mode ({{-Delytron}}), the next testing module ({{compat}}) fails.
It also brings difficulties when developing tests in the elytron test module itself.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3357) Implement filter in the right panel to avoid double mapping of the same property
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3357?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3357:
---------------------------------
Description:
Implement a filter in the right panel to avoid double mapping of the same properties. Max one mapping per property per section (GIVEN/EXPECT).
Make sure the filtering works for both rule-based and DMN-based test scenarios.
was:
Implement a filter in the right panel to avoid double mapping of the same properties. Max one mapping per property per section (GIVEN/EXPECT)
> Implement filter in the right panel to avoid double mapping of the same property
> --------------------------------------------------------------------------------
>
> Key: DROOLS-3357
> URL: https://issues.jboss.org/browse/DROOLS-3357
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
>
> Implement a filter in the right panel to avoid double mapping of the same properties. Max one mapping per property per section (GIVEN/EXPECT).
> Make sure the filtering works for both rule-based and DMN-based test scenarios.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFLY-11218:
------------------------------
Labels: blocker-WF17 (was: )
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Labels: blocker-WF17
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-11218:
-----------------------------------
Adding the blocker-WF17 label to move it out of the current blockers query at https://issues.jboss.org/issues/?filter=12335707
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Labels: blocker-WF17
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (SWSQE-584) Create rover group and pair it with istioci project
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-584?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-584.
---------------------------------
Resolution: Done
Rover group is linked to our project
> Create rover group and pair it with istioci project
> ---------------------------------------------------
>
> Key: SWSQE-584
> URL: https://issues.jboss.org/browse/SWSQE-584
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Critical
>
> There's a change in the authentication process in the new environment. In CI-RHOS we have used only local authentication and most teams only used shared account to login to the environment. In PSI (Upshift) we switched to LDAP authentication, thus you use your Kerberos credentials to log in to the system. What we do during the initial setup is paring of the Rover group name with the particular project and then it's up to Rover group admins to manage people who should be able to access the resources in PSI. That's why we need the Rover group name from you.
> When creating a Rover group please give it a different name than your LDAP group. Ambiguity could be a potential problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months