August 2020 - jboss-jira - Jboss List Archives

[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: Sunil Kondkar (was: Hayk Hovsepyan) > 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: Sunil Kondkar > 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

[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 updated SWSQE-1202: ---------------------------------- Sprint: Kiali Sprint #44 > 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: Sunil Kondkar > 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

[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2470: -------------------------------- Probably, yes, and [~rhusar] already submitted a PR to do this. I'll look into this today. But, please test with 4.2.5, to see if this fixes the issue. {{JDBC_PING.stop()}} calls {{super.stop()}}, so {{is_coord}} will be set to true. This is equivalent to removing the code, so you can go ahead and test. > JBDC_PING can face a split-brain issue when restarting a coordinator node > ------------------------------------------------------------------------- > > Key: JGRP-2470 > URL: https://issues.redhat.com/browse/JGRP-2470 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9, 4.0.22 > Reporter: Masafumi Miura > Assignee: Radoslav Husar > Priority: Major > Fix For: 4.2.5, 5.0.1 > > > After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node. > This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster. > 0. node1 and node2 form a cluster. The node1 is a coordinator. > 1. Trigger a restart of the node1 > 2. The node1 removes their node information from the table > 3. The node2 becomes a new coordinator > 4. The node2 updates their node information in the table > 5. The node1 clears all entries from the table > 6. The node1 starts again > 7. The node1 does not join the existing cluster because there's no node information in the table > Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13765) Change WebService DUP to use SecurityMetaData attachment

by Jim Ma (Jira)

Jim Ma created WFLY-13765: ----------------------------- Summary: Change WebService DUP to use SecurityMetaData attachment Key: WFLY-13765 URL: https://issues.redhat.com/browse/WFLY-13765 Project: WildFly Issue Type: Task Components: Web Services Affects Versions: 20.0.1.Final Reporter: Jim Ma Assignee: Jim Ma Mmigrate the WS DUPs to use SecurityMetaData so all these references into the Undertow and EJB subsystems can be dropped. https://github.com/wildfly/wildfly/pull/13478#pullrequestreview-465654990 -- 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 Andreas Weise (Jira)

[ https://issues.redhat.com/browse/WFLY-13763?page=com.atlassian.jira.plugi... ] Andreas Weise commented on WFLY-13763: -------------------------------------- some additional info from our debug session. we hunted the issue until [https://github.com/apache/santuario-java/blob/xmlsec-2.1.4/src/mai... that obviously compares different instances of _com.sun.xml.messaging.saaj.soap.impl.ElementImpl_. And within the debug session we also noticed that each time we inspected the ElementImpl objects (and their hierarchy), the instance ids changed a lot, so some getter or something else in SAAJ seems to create instances instead of passing references! That might have additional side-effects in other implementations... > 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] (DROOLS-5573) Review drools-scenario-simulation DMN examples version in codebase

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5573: -------------------------------------- Summary: Review drools-scenario-simulation DMN examples version in codebase Key: DROOLS-5573 URL: https://issues.redhat.com/browse/DROOLS-5573 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5572) Review kie-dmn-pmml-tests DMN examples version in codebase

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5572: -------------------------------------- Summary: Review kie-dmn-pmml-tests DMN examples version in codebase Key: DROOLS-5572 URL: https://issues.redhat.com/browse/DROOLS-5572 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ] Masafumi Miura commented on JGRP-2470: -------------------------------------- I saw [the fix|https://github.com/belaban/JGroups/commit/9b5aeb5ea28d99fb104dafe2e98...] that set {{is_coord}} to false in {{Discovery#stop()}}. Hmm, then, when will {{removeAll(cluster_name)}} in {{JDBC_PING#stop()}} be invoked? I think it will be never invoked. If so, isn't such an unused code better to be removed to avoid confusion? {code:title=jgroups/src/org/jgroups/protocols/JDBC_PING.java } 115 @Override 116 public void stop() { 117 super.stop(); 118 if(is_coord) // always false here because it's set to false in super.stop() 119 removeAll(cluster_name); 120 } {code} > JBDC_PING can face a split-brain issue when restarting a coordinator node > ------------------------------------------------------------------------- > > Key: JGRP-2470 > URL: https://issues.redhat.com/browse/JGRP-2470 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9, 4.0.22 > Reporter: Masafumi Miura > Assignee: Radoslav Husar > Priority: Major > Fix For: 4.2.5, 5.0.1 > > > After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node. > This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster. > 0. node1 and node2 form a cluster. The node1 is a coordinator. > 1. Trigger a restart of the node1 > 2. The node1 removes their node information from the table > 3. The node2 becomes a new coordinator > 4. The node2 updates their node information in the table > 5. The node1 clears all entries from the table > 6. The node1 starts again > 7. The node1 does not join the existing cluster because there's no node information in the table > Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13764) Hibernate 2LC uses wrong default cache configuration for timestamps regions

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13764: ----------------------------------- Summary: Hibernate 2LC uses wrong default cache configuration for timestamps regions Key: WFLY-13764 URL: https://issues.redhat.com/browse/WFLY-13764 Project: WildFly Issue Type: Bug Components: Clustering, JPA / Hibernate Affects Versions: 20.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro When query caching is enabled, Infinispan's region factory should, by default, use the "timestamps" cache configuration for timestamps region - however, it currently defaults to the "local-query" cache configuration. This is particularly problematic for HA configurations, which can cause applications to use a local-cache for timestamps (instead of a replicated-cache), resulting in stale queries being returned from the cache. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12442) Upgrade jboss-saaj-api and saaj-impl from 1.3 to 1.4

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12442?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12442: ----------------------------------------- Thanks; I filed WFLY-13763 to track your report. > Upgrade jboss-saaj-api and saaj-impl from 1.3 to 1.4 > ----------------------------------------------------- > > Key: WFLY-12442 > URL: https://issues.redhat.com/browse/WFLY-12442 > Project: WildFly > Issue Type: Sub-task > Components: Web Services > Reporter: Jim Ma > Assignee: Jim Ma > Priority: Blocker > Fix For: 18.0.0.Final > > -- 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