October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13828: ------------------------------- Issue Type: Feature Request (was: Bug) > remote+tls is not supported by EJBClient and remote-outbound-connection > ----------------------------------------------------------------------- > > Key: WFLY-13828 > URL: https://issues.redhat.com/browse/WFLY-13828 > Project: WildFly > Issue Type: Feature Request > Components: Remoting > Affects Versions: 20.0.1.Final > Reporter: Matthias Großmann > Assignee: Ranabir Chakraborty > Priority: Major > > Hi, > in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL. > This is possible with the Uri scheme "remote+tls" provided by jboss-remoting > https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav... > {code:java} > final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory(); > ... > endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); > {code} > But that uri scheme is not supported by the jboss-ejb-client in current version > https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... > {code} > public boolean supportsProtocol(final String uriScheme) { > switch (uriScheme) { > case "remote": > case "remote+http": > case "remote+https": > // compatibility > case "remoting": > case "http-remoting": > case "https-remoting": { > return true; > } > default: { > return false; > } > } > } > {code} > and also the remote-outbound-connection does not allow that protocol: > https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr... > {code} > public enum Protocol { > REMOTE("remote"), > REMOTE_HTTP("remote+http"), > HTTP_REMOTING("http-remoting"), > HTTPS_REMOTING("https-remoting"), > REMOTE_HTTPS("remote+https"); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1174) Use catalog sources instead of operator sources

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1174?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1174. ---------------------------------- Resolution: Done > Use catalog sources instead of operator sources > ----------------------------------------------- > > Key: SWSQE-1174 > URL: https://issues.redhat.com/browse/SWSQE-1174 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Operator sources will be removed in OCP 4.6, we need to start using catalog sources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1175) Use new form of rh-verified-operators and redhat-operators-stage

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1175?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1175. ---------------------------------- Resolution: Done https://docs.engineering.redhat.com/display/CFC/Test > Use new form of rh-verified-operators and redhat-operators-stage > ---------------------------------------------------------------- > > Key: SWSQE-1175 > URL: https://issues.redhat.com/browse/SWSQE-1175 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Currently we use rh-verified-operators to install pre-released versions of jaeger. We need to update our pipeline to use whatever will replace it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1175) Use new form of rh-verified-operators and redhat-operators-stage

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1175?page=com.atlassian.jira.plugi... ] Filip Brychta reassigned SWSQE-1175: ------------------------------------ Assignee: Filip Brychta > Use new form of rh-verified-operators and redhat-operators-stage > ---------------------------------------------------------------- > > Key: SWSQE-1175 > URL: https://issues.redhat.com/browse/SWSQE-1175 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Currently we use rh-verified-operators to install pre-released versions of jaeger. We need to update our pipeline to use whatever will replace it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1220) Update downstream pipeline to work with stage registry

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1220?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1220. ---------------------------------- Resolution: Done > Update downstream pipeline to work with stage registry > ------------------------------------------------------ > > Key: SWSQE-1220 > URL: https://issues.redhat.com/browse/SWSQE-1220 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > We want [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/main-pipelines...] to allow to choose stage registry - registry.stage.redhat.io -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13931) Allow defining HealthChecks without CDI

by Sebastian Laskawiec (Jira)

Sebastian Laskawiec created WFLY-13931: ------------------------------------------ Summary: Allow defining HealthChecks without CDI Key: WFLY-13931 URL: https://issues.redhat.com/browse/WFLY-13931 Project: WildFly Issue Type: Feature Request Components: MP Health Reporter: Sebastian Laskawiec Assignee: Jeff Mesnil The current design around MP Health enables deployments to specify HealthChecks using CDI. Some deployments (like Keycloak) doesn't use CDI at all. We would need a way to inject additional HealthCheck instances into Wildfly without enabling it. From the implementation perspective, it would be useful to have some sort of static accessor (or maybe something defined in jboss-structure.xml) that would enable use to inject some custom HealthCheck. References: * [Keycloak Observability Design|https://github.com/keycloak/keycloak-community/pull/177] * * [Keycloak Healthcheck Design|https://github.com/keycloak/keycloak-community/pull/55] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Ricardo Martin Camarero commented on ELY-2026: ---------------------------------------------- I can pass the test doing some reflection in the JDKSpecific for 8 as I commented in teh related JIRA. See this [commit|https://github.com/rmartinc/wildfly-elytron/commit/56f48d602e6e168...], it was just a quick hack, but it pass the test. Hope it helps! > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Major > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on ELY-2026: --------------------------------------- Thanks [~rhn-support-rmartinc] I will try some debugging, just wanted to eliminate if we already had a fix that just needed backporting but looks like there is still an issue. > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Major > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ] Ricardo Martin Camarero commented on ELY-2026: ---------------------------------------------- Yep, same result, the project uses elytron 1.12.1.Final but if you change it to current 1.x upstream the same exception is in the log. > UnsupportedOperationException in SSLEngine using jdk 251+ > --------------------------------------------------------- > > Key: ELY-2026 > URL: https://issues.redhat.com/browse/ELY-2026 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.10.9.Final > Reporter: Ricardo Martin Camarero > Assignee: Darran Lofthouse > Priority: Major > > Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception: > {code} > 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: > java.lang.reflect.InvocationTargetException > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81) > at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211) > at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97) > ... 8 more > Caused by: java.lang.UnsupportedOperationException > at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35) > at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166) > ... 13 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5143) Bouncycastle - Failing tests in RESTEasy TS

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5143?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-5143: ------------------------------------------ I need to run some tests, for KeyCloak I believe the main requirement is going to be - for our zip distribution the org.bouncycastle module must be present. For the provisioned cases I am going to test but the KeyCloak feature pack should trigger the dependency as it is installed I hope. > Bouncycastle - Failing tests in RESTEasy TS > ------------------------------------------- > > Key: WFCORE-5143 > URL: https://issues.redhat.com/browse/WFCORE-5143 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta6 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > Fix For: 13.0.0.Beta7 > > > [~ehugonnet] please set the component. I cannot find anything suitable. > I noticed it in the context of a bootable JAR execution but [~jfdenise] confirmed this happens with WF 21 Beta1. > This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1]. > The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression. > There are 108 tests failing but this JIRA is reporting just one as a reference, see "Steps to reproduce" in order to have a full list: > {code} > org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest.org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest > Error Details > Cannot deploy BlacklistedMediaTypeTest.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.BlacklistedMediaTypeTest.war\".main" => "WFLYSRV0179: Failed to load module: deployment.BlacklistedMediaTypeTest.war > Caused by: org.jboss.modules.ModuleNotFoundException: org.bouncycastle"}}}} > {code} > *Steps to reproduce*: > 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support > 2. build RESTEasy: > {code} > $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo > {code} > 3. cd to testsuite directory: > {code} > cd testsuite > {code} > 4. run the test against WF 21.0.0.Beta1 with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *fail* > 5. run the test against WF 20.0.1.Final with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *pass* > [1] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... > [2] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020