May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3577) Add support for coloured output to CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3577?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3577: ---------------------------------------- Assignee: Ingo Weiss (was: Jean-Francois Denise) > Add support for coloured output to CLI > -------------------------------------- > > Key: WFCORE-3577 > URL: https://issues.jboss.org/browse/WFCORE-3577 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 4.0.0.Alpha10 > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Fix For: 5.0.0.Beta1 > > > Add support to colour for CLI outputs -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-136) java.util.logging.LogManager removed deprecated property change listeners

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-136?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-136: ------------------------------------ Fix Version/s: 2.1.0.Final (was: 2.1.2.Final) Assignee: James Perkins Resolution: Done > java.util.logging.LogManager removed deprecated property change listeners > ------------------------------------------------------------------------- > > Key: LOGMGR-136 > URL: https://issues.jboss.org/browse/LOGMGR-136 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Final > > > Both the {{addPropertyChangeListener(PropertyChangeListener}} and {{removePropertyChangeListener(PropertyChangeListener}} were deprecated in Java 8 and removed in Java 9. There are two new replacement methods {{addConfigurationListener(Runnable)}} and {{removeConfigurationListener(Runnable)}} that have been added as replacements. > For the JBoss Log Manager these could likely be no-ops like the originals were. > In Java 9 to {{updateConfiguration()}} methods were added as well. These should also be overridden with no-ops. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-136) java.util.logging.LogManager removed deprecated property change listeners

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-136?page=com.atlassian.jira.plugin... ] James Perkins reopened LOGMGR-136: ---------------------------------- > java.util.logging.LogManager removed deprecated property change listeners > ------------------------------------------------------------------------- > > Key: LOGMGR-136 > URL: https://issues.jboss.org/browse/LOGMGR-136 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Final > > > Both the {{addPropertyChangeListener(PropertyChangeListener}} and {{removePropertyChangeListener(PropertyChangeListener}} were deprecated in Java 8 and removed in Java 9. There are two new replacement methods {{addConfigurationListener(Runnable)}} and {{removeConfigurationListener(Runnable)}} that have been added as replacements. > For the JBoss Log Manager these could likely be no-ops like the originals were. > In Java 9 to {{updateConfiguration()}} methods were added as well. These should also be overridden with no-ops. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-200) B12 OpenShift Cluster is flaky

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-200?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo edited comment on SWSQE-200 at 5/9/18 3:21 PM: ----------------------------------------------------------------------- Hi [~kearls] B12 is an old blade cluster (b11, b12, b14). I verified that jaeger-test pods are being deployed on b11 alongside with istio-system. This node seems to be running okay (No CPU probably, No memory Requests, No memory Limit problems) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 1400m (8%) 0 (0%) 17966569056 (35%) 22779069056 (45%) I can add b13 to this cluster... set project to specific node like b13 or b12. What do you think? We still have b24 and b25 (which are the newest blades) ... we can use that as well [~fbrychta]? was (Author: gbaufake): Hi [~kearls] B12 is an old blade cluster (b11, b12, b14). I verified that jaeger-test pods are being deployed on b11 alongside with istio-system. This node seems to be running okay (No CPU probably, No memory Requests, No memory Limit problems) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 1400m (8%) 0 (0%) 17966569056 (35%) 22779069056 (45%) I can add b13 to this cluster... set project to specific node like b13 or b12. What do you think? We still b24 and b25 (which are the newest blades) ... we can use that as well [~fbrychta]? > B12 OpenShift Cluster is flaky > ------------------------------ > > Key: SWSQE-200 > URL: https://issues.jboss.org/browse/SWSQE-200 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Guilherme Baufaker Rêgo > > I'm opening this mostly as a placeholder, and will update it as I get more information on the problems I've been experiencing. Since I've been using B12 I've been experiencing more frequent failures than on other clusters, including minishift on my laptop and the CNCF CI Jenkins. Here are a couple of instances: > 1. Deploying ElasticSearch along with the Jaeger Production templates requires allocating 2G or memory, even though the default 512M works fine elsewhere. This can be seen in the Jaeger Standalone Performance tests job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/J... . If you run the job without changing the ES_MEMORY parameter to 2Gi it will fail. > 2. I have a set of smoke tests for Red Hat productized artifacts for the Jaeger Java client which are run using the Jaeger all-in-one template. It's fairly simple, but on B12 deployment of the Jaeger all-in-one images fails on every other build. I've made a copy of the job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/F... and its history should be clear. > So far I have not been able to get any useful information about why this is failing. In the OpenShift console it looks like Jaeger has started correctly. There are no errors in the logs, nor any to be found under monitoring. But if you click on the Jaeger link, you get the message "Application is not available . The application is currently not serving requests at this endpoint. It may not have been started or is still starting." -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-200) B12 OpenShift Cluster is flaky

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-200?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-200: ----------------------------------------------- Hi [~kearls] B12 is an old blade cluster (b11, b12, b14). I verified that jaeger-test pods are being deployed on b11 alongside with istio-system. This node seems to be running okay (No CPU probably, No memory Requests, No memory Limit problems) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 1400m (8%) 0 (0%) 17966569056 (35%) 22779069056 (45%) I can add b13 to this cluster... set project to specific node like b13 or b12. What do you think? We still b24 and b25 (which are the newest blades) ... we can use that as well [~fbrychta]? > B12 OpenShift Cluster is flaky > ------------------------------ > > Key: SWSQE-200 > URL: https://issues.jboss.org/browse/SWSQE-200 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Guilherme Baufaker Rêgo > > I'm opening this mostly as a placeholder, and will update it as I get more information on the problems I've been experiencing. Since I've been using B12 I've been experiencing more frequent failures than on other clusters, including minishift on my laptop and the CNCF CI Jenkins. Here are a couple of instances: > 1. Deploying ElasticSearch along with the Jaeger Production templates requires allocating 2G or memory, even though the default 512M works fine elsewhere. This can be seen in the Jaeger Standalone Performance tests job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/J... . If you run the job without changing the ES_MEMORY parameter to 2Gi it will fail. > 2. I have a set of smoke tests for Red Hat productized artifacts for the Jaeger Java client which are run using the Jaeger all-in-one template. It's fairly simple, but on B12 deployment of the Jaeger all-in-one images fails on every other build. I've made a copy of the job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/F... and its history should be clear. > So far I have not been able to get any useful information about why this is failing. In the OpenShift console it looks like Jaeger has started correctly. There are no errors in the logs, nor any to be found under monitoring. But if you click on the Jaeger link, you get the message "Application is not available . The application is currently not serving requests at this endpoint. It may not have been started or is still starting." -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFLY-10229. ------------------------------- > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-10229: ------------------------------------- >From my EE testing, this appears to be fixed, however, I'm now hitting what may be either a test or Hibernate ORM issue. > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-140) Kiali-UI Test Framework Using kiali-python-client

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-140?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated SWSQE-140: --------------------------------- Sprint: Kiali QE Sprint 4, Kiali QE Sprint 5 (was: Kiali QE Sprint 4) > Kiali-UI Test Framework Using kiali-python-client > ------------------------------------------------- > > Key: SWSQE-140 > URL: https://issues.jboss.org/browse/SWSQE-140 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-140) Kiali-UI Test Framework Using kiali-python-client

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-140?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated SWSQE-140: --------------------------------- Team: Automation (was: Automation) > Kiali-UI Test Framework Using kiali-python-client > ------------------------------------------------- > > Key: SWSQE-140 > URL: https://issues.jboss.org/browse/SWSQE-140 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-140) Kiali-UI Test Framework Using kiali-python-client

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-140?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated SWSQE-140: --------------------------------- Sprint: Kiali QE Sprint 4 (was: Kiali QE Sprint 4, Kiali QE Sprint 5) > Kiali-UI Test Framework Using kiali-python-client > ------------------------------------------------- > > Key: SWSQE-140 > URL: https://issues.jboss.org/browse/SWSQE-140 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 May 2018