June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1181) DropDown - Check open and close states first - optimize

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1181?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1181: ---------------------------------- Sprint: Kiali Sprint #41 > DropDown - Check open and close states first - optimize > ------------------------------------------------------- > > Key: SWSQE-1181 > URL: https://issues.redhat.com/browse/SWSQE-1181 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1186) Applications list test - Add back labels comparison

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1186?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan closed SWSQE-1186. --------------------------------- Resolution: Duplicate Issue > Applications list test - Add back labels comparison > --------------------------------------------------- > > Key: SWSQE-1186 > URL: https://issues.redhat.com/browse/SWSQE-1186 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > > Applications UI list comparing to OC list, labels are disabled. > Should be enabled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13589) WildFly cannot connect to an infinispan-server cluster requiring authentication

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13589?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13589: -------------------------------- Issue Type: Bug (was: Feature Request) > WildFly cannot connect to an infinispan-server cluster requiring authentication > ------------------------------------------------------------------------------- > > Key: WFLY-13589 > URL: https://issues.redhat.com/browse/WFLY-13589 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. > See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13589) WildFly cannot connect to an infinispan-server cluster requiring authentication

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13589?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13589: -------------------------------- Summary: WildFly cannot connect to an infinispan-server cluster requiring authentication (was: Add support for configuring RHDG authentication over hotrod) > WildFly cannot connect to an infinispan-server cluster requiring authentication > ------------------------------------------------------------------------------- > > Key: WFLY-13589 > URL: https://issues.redhat.com/browse/WFLY-13589 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. > See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1725) Remove 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Ashley Abdel-Sayed (Jira)

[ https://issues.redhat.com/browse/ELY-1725?page=com.atlassian.jira.plugin.... ] Ashley Abdel-Sayed commented on ELY-1725: ----------------------------------------- [~noelvaes] ELY-1724 would copy the {{org.wildfly.security.credential.source.OAuth2CredentialSource}} from the authentication client module to the credential source module. > Remove 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ---------------------------------------------------------------------- > > Key: ELY-1725 > URL: https://issues.redhat.com/browse/ELY-1725 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 2.0.0.Alpha8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ] Sonia Zaldana commented on WFCORE-5004: --------------------------------------- When the X500Principal is extracted from the X509Certificate, it contains the email address in encoded form in the canonical representation, so we need to use getName() instead which will use the RFC 2253 representation. > TlsTestCase#testReloadTrustManager fails on IBM Java 8 > ------------------------------------------------------ > > Key: WFCORE-5004 > URL: https://issues.redhat.com/browse/WFCORE-5004 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Sonia Zaldana > Priority: Major > > TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL)); > [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...> > {noformat} > Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName()); > {noformat} > The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ] Sonia Zaldana updated WFCORE-5004: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4236 > TlsTestCase#testReloadTrustManager fails on IBM Java 8 > ------------------------------------------------------ > > Key: WFCORE-5004 > URL: https://issues.redhat.com/browse/WFCORE-5004 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Sonia Zaldana > Priority: Major > > TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL)); > [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...> > {noformat} > Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName()); > {noformat} > The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1187) Workloads list test - Add back labels comparison

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1187: ------------------------------------- Summary: Workloads list test - Add back labels comparison Key: SWSQE-1187 URL: https://issues.redhat.com/browse/SWSQE-1187 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Label comparison between OC and UI. In Workloads lists test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1185) OC API - workload_list - apply Job/Pod filters

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1185?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1185: ---------------------------------- Description: openshift_api.workload_list # TODO apply Job filters # TODO apply Pod filters Activate in workload lists test: # TODO when workloads are filtered put == here was: openshift_api.workload_list # TODO apply Job filters # TODO apply Pod filters > OC API - workload_list - apply Job/Pod filters > ---------------------------------------------- > > Key: SWSQE-1185 > URL: https://issues.redhat.com/browse/SWSQE-1185 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > > openshift_api.workload_list > # TODO apply Job filters > # TODO apply Pod filters > > Activate in workload lists test: > # TODO when workloads are filtered put == here -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5437) Unable to deploy project to kie server

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5437?page=com.atlassian.jira.plug... ] Yeser Amer commented on DROOLS-5437: ------------------------------------ Hi [~adupliak], I tried to reproduce it and I have the same behavior reported by [~jomarko]. I think this is not related to Test Scenario, so I strongly recommend to re-address it or to require support by Appformer team. > Unable to deploy project to kie server > -------------------------------------- > > Key: DROOLS-5437 > URL: https://issues.redhat.com/browse/DROOLS-5437 > Project: Drools > Issue Type: Bug > Affects Versions: 7.39.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Blocker > Labels: drools-tools > Attachments: Screenshot from 2020-06-17 07-29-32.png, c.d is undefined 2.scesim, c.d is undefined.scesim, error.log, image-2020-06-16-21-39-06-147.png, undefinedType.webm > > > Cannot deploy any project to kie-server > Kie server fails deploying project with message [^c.d is undefined.scesim] [^c.d is undefined 2.scesim] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 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 June 2020