July 2019 - jboss-jira - Jboss List Archives

[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)

4 years, 9 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)

4 years, 9 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)

4 years, 9 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)

4 years, 9 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)

4 years, 9 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)

4 years, 9 months

1
0
0 / 0

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

by Martin Choma (Jira)

Martin Choma created WFWIP-167: ---------------------------------- Summary: 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 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)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12295) Deployments fails if de.odysseus.juel is included in the war

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12295?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12295: ----------------------------------- Labels: downstream_dependency (was: ) > Deployments fails if de.odysseus.juel is included in the war > ------------------------------------------------------------- > > Key: WFLY-12295 > URL: https://issues.jboss.org/browse/WFLY-12295 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Major > Labels: downstream_dependency > > If the war file contains spring-mvc and de.odysseus.juel in WEB-INF/lib, the deployment fails with the following message. The deployment is successful on EAP7.0.9 and EAP7.1.0, but it fails on EAP7.2.x. > This behavior breaks backward compatibility between EAP7.1 and EAP7.2. > {noformat} > 14:55:59,808 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 73) MSC000001: Failed to start service jboss.deployment.unit."reproduce.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."reproduce.war".undertow-deployment: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78) > ... 8 more > Caused by: java.lang.RuntimeException: java.lang.NullPointerException > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:315) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:216) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:185) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:250) > ... 10 more > Caused by: java.lang.NullPointerException > at javax.el.CompositeELResolver.add(CompositeELResolver.java:117) > at com.sun.faces.el.DemuxCompositeELResolver.addRootELResolver(DemuxCompositeELResolver.java:142) > at com.sun.faces.el.ELUtils.addEL3_0_Resolvers(ELUtils.java:336) > at com.sun.faces.el.ELUtils.buildFacesResolver(ELUtils.java:258) > at com.sun.faces.application.ApplicationAssociate.initializeELResolverChains(ApplicationAssociate.java:503) > at com.sun.faces.application.ApplicationImpl.performOneTimeELInitialization(ApplicationImpl.java:1405) > at com.sun.faces.application.ApplicationImpl.getELResolver(ApplicationImpl.java:529) > at javax.faces.application.ApplicationWrapper.getELResolver(ApplicationWrapper.java:621) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:256) > ... 21 more > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12336: ----------------------------------- Component/s: JSF > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 17.0.1.Final > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12336: ----------------------------------- Affects Version/s: 17.0.1.Final > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 17.0.1.Final > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 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 July 2019