July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-883) Increase code coverage above 80% for github.com/kiali/kiali/business/checkers/gateways (UI tests)

by Filip Brychta (Jira)

Filip Brychta created SWSQE-883: ----------------------------------- Summary: Increase code coverage above 80% for github.com/kiali/kiali/business/checkers/gateways (UI tests) Key: SWSQE-883 URL: https://issues.jboss.org/browse/SWSQE-883 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Read parent task for details. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-881) Increase code coverage above 80% for github.com/kiali/kiali/business (UI tests)

by Filip Brychta (Jira)

Filip Brychta created SWSQE-881: ----------------------------------- Summary: Increase code coverage above 80% for github.com/kiali/kiali/business (UI tests) Key: SWSQE-881 URL: https://issues.jboss.org/browse/SWSQE-881 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Read parent task for details. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-882) Increase code coverage above 80% for github.com/kiali/kiali/business/checkers/authorization (UI tests)

by Filip Brychta (Jira)

Filip Brychta created SWSQE-882: ----------------------------------- Summary: Increase code coverage above 80% for github.com/kiali/kiali/business/checkers/authorization (UI tests) Key: SWSQE-882 URL: https://issues.jboss.org/browse/SWSQE-882 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Read parent task for details. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-880) Increase code coverage above 80% for github.com/kiali/kiali (UI tests)

by Filip Brychta (Jira)

Filip Brychta created SWSQE-880: ----------------------------------- Summary: Increase code coverage above 80% for github.com/kiali/kiali (UI tests) Key: SWSQE-880 URL: https://issues.jboss.org/browse/SWSQE-880 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Read parent task for details. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-879) Increase code coverage above 80% (UI tests)

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-879?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-879: -------------------------------- Description: There will be sub task for each package which is not covered at least by 80% For each sub task you can: * add new tests to increase coverage above 80% * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80% * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report See chapter How to get the latest code coverage in https://docs.jboss.org/display/SWSQE/Code+coverage+for+system+tests to generate the latest code coverage. > Increase code coverage above 80% (UI tests) > ------------------------------------------- > > Key: SWSQE-879 > URL: https://issues.jboss.org/browse/SWSQE-879 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Priority: Major > Labels: automation > > There will be sub task for each package which is not covered at least by 80% > For each sub task you can: > * add new tests to increase coverage above 80% > * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80% > * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report > See chapter How to get the latest code coverage in https://docs.jboss.org/display/SWSQE/Code+coverage+for+system+tests to generate the latest code coverage. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-879) Increase code coverage above 80% (UI tests)

by Filip Brychta (Jira)

Filip Brychta created SWSQE-879: ----------------------------------- Summary: Increase code coverage above 80% (UI tests) Key: SWSQE-879 URL: https://issues.jboss.org/browse/SWSQE-879 Project: Kiali QE Issue Type: Story Reporter: Filip Brychta -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFWIP-167: ------------------------------------ User Scenario: User change external standalone.xml and want to apply changes. Does operator provide support for applying changes without service outage? E.g restart pods one by one? > EAP Operator handling ConfigMap internally > ------------------------------------------ > > Key: WFWIP-167 > URL: https://issues.jboss.org/browse/WFWIP-167 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > > If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap. > Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users. > Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me. > However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator. > What do you think? Have you considered this approach? > [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4058) Add inheritance goal to kie-gwthelper-maven-plugin

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4058?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4058: ------------------------------------- Summary: Add inheritance goal to kie-gwthelper-maven-plugin (was: Add analyze goal to kie-gwthelper-maven-plugin) > Add inheritance goal to kie-gwthelper-maven-plugin > -------------------------------------------------- > > Key: DROOLS-4058 > URL: https://issues.jboss.org/browse/DROOLS-4058 > Project: Drools > Issue Type: Enhancement > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > Implement an "analyze" goal to the plugin to verify that all indirectly inherited modules are present in the classpath without having to invoke gwt compilation -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4058) Add inheritance goal to kie-gwthelper-maven-plugin

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4058?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4058: ------------------------------------- Description: Implement an "inheritance" goal to the plugin to verify that all indirectly inherited modules are present in the classpath without having to invoke gwt compilation (was: Implement an "analyze" goal to the plugin to verify that all indirectly inherited modules are present in the classpath without having to invoke gwt compilation) > Add inheritance goal to kie-gwthelper-maven-plugin > -------------------------------------------------- > > Key: DROOLS-4058 > URL: https://issues.jboss.org/browse/DROOLS-4058 > Project: Drools > Issue Type: Enhancement > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > Implement an "inheritance" goal to the plugin to verify that all indirectly inherited modules are present in the classpath without having to invoke gwt compilation -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated WFLY-12317: ------------------------------------ Forum Reference: https://developer.jboss.org/thread/280430 > Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed > --------------------------------------------------------------------------------------------------- > > Key: WFLY-12317 > URL: https://issues.jboss.org/browse/WFLY-12317 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 17.0.0.Final > Reporter: Ivan Straka > Assignee: Michael Musgrove > Priority: Critical > Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log > > > We have following test scenario (3 servers) that fails: > # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property) > # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped > # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded > # server3 is running > # client call an EJB bean (where a transaction is started) on the server1 > # the EJB sends JMS message to the server3 (broker) > # the EJB enlists dummy xa resource > # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked > # we move server1 object store directory to the server2 > # server2 is started > # the server2 is expected to rollback whole transaction > Transaction is unfinished because server2 has not performed rollback. > {code:java} > prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE! > java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1 > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792) > at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565) > {code} > In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X. > I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback. > See node_name > Server1: > {code:java} > 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed > {code} > {code:java} > 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47 > {code} > Server2: > > {code:java} > 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed > {code} > {code:java} > 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd > 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN > {code} > *When does the scenario pass* > When I run the TS with > {code:java} > -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid > {code} > the test passes (old and new node-identifier on both servers are same) > When step 3 slightly differs: > When restart is performed instead of reload op. > Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid > *tldr;* > The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 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 July 2019