August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13766) MicroProfile OpenAPI subsystem cannot be used in legacy feature packs

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13766: ----------------------------------- Summary: MicroProfile OpenAPI subsystem cannot be used in legacy feature packs Key: WFLY-13766 URL: https://issues.redhat.com/browse/WFLY-13766 Project: WildFly Issue Type: Task Components: MP OpenAPI Affects Versions: 20.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Supply a subsystem xml file in the subsystem jar so this subsystem can be used in legacy feature packs. This is a specific request from the Keycloak team, so they can use MicroProfile OpenAPI until they migrate their distribution to the galleon. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13672) Upgrade JGroups to 4.2.5.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13672?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13672: -------------------------------- Description: Tracker for 4.2.5.Final release. Code changes [https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-...] ...tag has not been pushed for this release, so use this link [https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73...] Release Notes: [https://issues.redhat.com/projects/JGRP/versions/12345857] was: Tracker for 4.2.5.Final release. Code changes https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... ...tag has not been pushed for this release, so use this link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73... > Upgrade JGroups to 4.2.5.Final > ------------------------------ > > Key: WFLY-13672 > URL: https://issues.redhat.com/browse/WFLY-13672 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Tracker for 4.2.5.Final release. > Code changes > [https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-...] > ...tag has not been pushed for this release, so use this link [https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73...] > Release Notes: [https://issues.redhat.com/projects/JGRP/versions/12345857] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13763) WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4

by Jim Ma (Jira)

[ https://issues.redhat.com/browse/WFLY-13763?page=com.atlassian.jira.plugi... ] Jim Ma commented on WFLY-13763: ------------------------------- [~weiseand] Do you mean this line should be equal and break [https://github.com/apache/santuario-java/blob/xmlsec-2.1.4/src/mai... We found this change breaks couple of things : [https://github.com/javaee/metro-saaj/commit/148757613467ee3c60ac8db364c80cc842348713] Is this issue related to this change too? > WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4 > ------------------------------------------------------------ > > Key: WFLY-13763 > URL: https://issues.redhat.com/browse/WFLY-13763 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: Brian Stansberry > Assignee: Jim Ma > Priority: Major > > This was reported by Andreas Weise at https://groups.google.com/g/wildfly/c/B4Gk4ljbrqE: > After upgrading to WFY20 we are facing a regression regarding WS-Security that was introduced with Upgrade of com.sun.xml.messaging.saaj:saaj-impl in https://issues.redhat.com/browse/WFLY-12442 with WFLY18. When downgrading com.sun.xml.messaging.saaj:saaj-impl to 1.3.x the regression is fixed also in WFLY18+. We did not locate the root cause in saaj-impl 1.4+. > The Bug was spotted within our signing algorithm used for our SOAP Web Services (which uses javax.xml.crypto.dsig Packages). > The Bug can be reproduced easily via https://github.com/weand/wildfly-xml-sig-reproducer, which contains the most basic reproducer code of our scenario: > Reproducer contains a Web Service implementation which uses XML Signature and more specifically the enveloped-signature transform algorithm (https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature). This standard transform algorithm basically removes the whole Signature element from the digest calculation. And thats not stable since WFLY18 as the Signature element is not removed anymore! The repo also contains an arquillian test testing the SOAP webservice response using rest-assured. > Run good scenario: Test on WFLY17 > 1) mvn clean install -Pwfly17 > 2) Test passes > 3) see proper 'Pre-digested input' as DEBUG output of org.apache.jcp Logger (here I pretty formatted the XML): > {code} > 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input: > 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body"> > <ns1:echoResponse > xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/"> > <return>hello test</return> > </ns1:echoResponse> > </soap:Body> > 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body > 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed > {code} > Run failing scenario: Test on WFLY18+ > 1) mvn clean install (which defaults to 20.0.1.Final) > 2) Test fails > {code} > [ERROR] testService(com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT) Time elapsed: 0.874 s <<< FAILURE! > java.lang.AssertionError: > Expected: Expected text value '0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=' but was 'A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=' - comparing <DigestValue ...>0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1] to <DigestValue ...>A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1]: > <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue> > but: result was: > <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue> > at com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT.testService(XmlSignatureIT.java:71) > {code} > 3) see invalid 'Pre-digested input' as DEBUG output of org.apache.jcp Logger: > {code} > 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input: > 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body"> > <ns1:echoResponse > xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/"> > <return>hello test</return> > </ns1:echoResponse> > <Signature > xmlns="http://www.w3.org/2000/09/xmldsig#"> > <SignedInfo> > <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod> > <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod> > <Reference URI="#Body"> > <Transforms> > <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform> > </Transforms> > <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod> > <DigestValue></DigestValue> > </Reference> > </SignedInfo> > <SignatureValue></SignatureValue> > </Signature> > </soap:Body> > 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body > 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed > {code} > Again the digest with enveloped-signature transform algorithm works properly when downgrading saaj-impl to 1.3.x in WFLY18+. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2490) MPerf changes

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2490?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2490: --------------------------- Fix Version/s: 5.0.2 (was: 5.0.1) > MPerf changes > ------------- > > Key: JGRP-2490 > URL: https://issues.redhat.com/browse/JGRP-2490 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0.2 > > > Make MPerf more similar to UPerf: > * Time based > * Better reporting > * Simplifications > * Also look at performance after the changes -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1203) Use FC (Feature Candidate) instead of nightlies for LP testing

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1203?page=com.atlassian.jira.plugi... ] Filip Brychta updated SWSQE-1203: --------------------------------- Sprint: Kiali Sprint #44 (was: Kiali Sprint #31) > Use FC (Feature Candidate) instead of nightlies for LP testing > -------------------------------------------------------------- > > Key: SWSQE-1203 > URL: https://issues.redhat.com/browse/SWSQE-1203 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: infrastructure > > {color:#000000}Hi All,{color} > {color:#000000} {color} > {color:#000000}ART will start creating FC (Feature Candidate) after feature freeze date, reason for doing it is because we want to give access to new releases to layered product teams as soon as possible. We are calling it FC and not RC (Release Candidate) because the releases are being built before code freeze and there is no potential for the release to GA. After code freeze, we will begin releasing Release Candidates as we have always done. Nightlies continue to build with the same cadence and will continue to publish the same way.{color} > > {color:#000000}FC is basically a nightly payload (signed with the Beta2 Red Hat key) which is added to the candidate channel, it does not have any signed RPM content. Once we start creating FC ART won’t stop mirroring nightlies to openshift mirror, only after RC (Release Candidate) creation that will happen because RC is actual Release Candidate and it has all the signed content.{color} > > {color:#000000}ART will publish FC once in a week, every friday. First FC for OCP 4.6 will appear in the candidate channel this friday.{color} > > {color:#000000}If you have any questions or issues related to this please reach out to ART team on slack in #aos-art channel.{color} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1203) Use FC (Feature Candidate) instead of nightlies for LP testing

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1203: ------------------------------------ Summary: Use FC (Feature Candidate) instead of nightlies for LP testing Key: SWSQE-1203 URL: https://issues.redhat.com/browse/SWSQE-1203 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta {color:#000000}Hi All,{color} {color:#000000} {color} {color:#000000}ART will start creating FC (Feature Candidate) after feature freeze date, reason for doing it is because we want to give access to new releases to layered product teams as soon as possible. We are calling it FC and not RC (Release Candidate) because the releases are being built before code freeze and there is no potential for the release to GA. After code freeze, we will begin releasing Release Candidates as we have always done. Nightlies continue to build with the same cadence and will continue to publish the same way.{color} {color:#000000}FC is basically a nightly payload (signed with the Beta2 Red Hat key) which is added to the candidate channel, it does not have any signed RPM content. Once we start creating FC ART won’t stop mirroring nightlies to openshift mirror, only after RC (Release Candidate) creation that will happen because RC is actual Release Candidate and it has all the signed content.{color} {color:#000000}ART will publish FC once in a week, every friday. First FC for OCP 4.6 will appear in the candidate channel this friday.{color} {color:#000000}If you have any questions or issues related to this please reach out to ART team on slack in #aos-art channel.{color} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13672) Upgrade JGroups to 4.2.5.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13672?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13672: ---------------------------------- Description: Tracker for 4.2.5.Final release. Code changes https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... ...tag has not been pushed for this release, so use this link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73... was: Tracker for 4.2.5.Final release. Code changes https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... (will be available after release in the meantime use link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...4.x) > Upgrade JGroups to 4.2.5.Final > ------------------------------ > > Key: WFLY-13672 > URL: https://issues.redhat.com/browse/WFLY-13672 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Tracker for 4.2.5.Final release. > Code changes > https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... > ...tag has not been pushed for this release, so use this link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13672) Upgrade JGroups to 4.2.5.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13672?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13672: ---------------------------------- Affects Version/s: 20.0.1.Final > Upgrade JGroups to 4.2.5.Final > ------------------------------ > > Key: WFLY-13672 > URL: https://issues.redhat.com/browse/WFLY-13672 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Tracker for 4.2.5.Final release. > Code changes > https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... > ...tag has not been pushed for this release, so use this link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13672) Upgrade JGroups to 4.2.5.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13672?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13672: ---------------------------------- Fix Version/s: 21.0.0.Beta1 > Upgrade JGroups to 4.2.5.Final > ------------------------------ > > Key: WFLY-13672 > URL: https://issues.redhat.com/browse/WFLY-13672 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Tracker for 4.2.5.Final release. > Code changes > https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...JGroups-... > ...tag has not been pushed for this release, so use this link https://github.com/belaban/JGroups/compare/JGroups-4.2.4.Final...32190c73... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1202) UI Automations - Overview Filters Apply

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1202?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1202: ------------------------------------- Assignee: Hayk Hovsepyan (was: Sunil Kondkar) > UI Automations - Overview Filters Apply > --------------------------------------- > > Key: SWSQE-1202 > URL: https://issues.redhat.com/browse/SWSQE-1202 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Overview page contains Filter options. > We need to automate all filter types apply and result checking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020