August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1208) UI Automations - Fix random failures

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1208?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1208: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/324 > UI Automations - Fix random failures > ------------------------------------ > > Key: SWSQE-1208 > URL: https://issues.redhat.com/browse/SWSQE-1208 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/run-kiali-ui-te... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFWIP-339: ------------------------------ Summary: OpenSSL security provider seems to be used when not defined with JDK8 now (was: OpenSSL security provider seems to be used when not defined now) > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFWIP-339: ------------------------------ Description: It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: {quote} 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 {quote} This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: {code} <server-ssl-contexts> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> </server-ssl-contexts> <client-ssl-contexts> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> </client-ssl-contexts> {code} There are two questions from this: # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. Hope I don't have any misconfiguration in the configuration itself. was: It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: {quote} 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 {quote} There are two questions from this: # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Hope I don't have any misconfiguration in the configuration itself. > OpenSSL security provider seems to be used when not defined now > --------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFWIP-339: ------------------------------ Steps to Reproduce: # build server from relevant sources based on the work of EAP7-1414: {code} https://github.com/wildfly-security/wildfly-openssl-natives/pull/1 https://github.com/wildfly-security/wildfly-openssl/pull/81 https://github.com/undertow-io/undertow/commit/818bfe3979cf9001660ee50718... (current master) https://github.com/wildfly/wildfly-core/commit/346e1b30e1f58ec1fe5805eb2c... (current master) https://github.com/wildfly/wildfly/commits/master (current master) {code} # copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory # start server {code:java} JAVA_HOME=<path_to_jdk8> ./bin/standalone.sh -c standalone-full.xml {code} # see relevant `WFOPENSSL0002` message is present during the server boot was: # build server from relevant sources based on the work of EAP7-1414: {code} https://github.com/wildfly-security/wildfly-openssl-natives/pull/1 https://github.com/wildfly-security/wildfly-openssl/pull/81 https://github.com/undertow-io/undertow/commit/818bfe3979cf9001660ee50718... (current master) https://github.com/wildfly/wildfly-core/commit/346e1b30e1f58ec1fe5805eb2c... (current master) https://github.com/wildfly/wildfly/commits/master (current master) {code} # copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory # start server {code:java} ./bin/standalone.sh -c standalone-full.xml {code} # see relevant `WFOPENSSL0002` message is present during the server boot > OpenSSL security provider seems to be used when not defined now > --------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13779) MicroProfile Metrics tests started to fail since changes in ConfigSource

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13779?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13779: ------------------------------------ When is the `config.source.properties.path` system property set? With https://github.com/wildfly/wildfly/pull/13247 changes, the config source can now be read by other subsystems before any deployment is done. If the sys prop was set during deployment while the config source was configured by the subsystems, that would be an issue in the test fixture. > MicroProfile Metrics tests started to fail since changes in ConfigSource > ------------------------------------------------------------------------ > > Key: WFLY-13779 > URL: https://issues.redhat.com/browse/WFLY-13779 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Sultan Zhantemirov > Assignee: Jeff Mesnil > Priority: Major > > WildFly build: 21.0.0.Beta1-SNAPSHOT > Java: oracle-java-11 > A several failures appeared in our small standalone test suite [1] for MicroProfile on WF/EAP. To be more specific, a few failures in MP Metrics that have one common cause: > {noformat} > java.lang.RuntimeException: config.source.properties.path property not defined > {noformat} > caused by line [2]. > I have a reason to believe that this PR [3] could be reason of these failures. What should be done in this case? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/tree/master/m... > [2] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/blob/8b726042... > [3] - https://github.com/wildfly/wildfly/pull/13247 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Alojzij Blatnik (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Alojzij Blatnik commented on WFLY-13808: ---------------------------------------- Hi. Thanks for the information. I attached the patch here. It can be applied on top of wildfly-core, tag 12.0.3.Final. Br. [^diff.patch] > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > Attachments: diff.patch > > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Alojzij Blatnik (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Alojzij Blatnik updated WFLY-13808: ----------------------------------- Attachment: diff.patch > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > Attachments: diff.patch > > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13810: --------------------------------------- Assignee: Brian Stansberry (was: Paul Ferraro) > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFLY-13810 at 8/30/20 6:17 PM: ------------------------------------------------------------------ Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. https://ci.wildfly.org/viewLog.html?buildId=219289&buildTypeId=WF_PullReq... was (Author: brian.stansberry): Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13810: ------------------------------------ Priority: Critical (was: Major) Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020