December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4845) Fix error-popover position on simulation/model grids

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4845?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4845: -------------------------------- Git Pull Request: (was: https://github.com/kiegroup/drools-wb/pull/1271) > Fix error-popover position on simulation/model grids > ---------------------------------------------------- > > Key: DROOLS-4845 > URL: https://issues.redhat.com/browse/DROOLS-4845 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Jozef Marko > Assignee: Gabriele Cardosi > Priority: Major > > When there is only one column on the grid, the popover is show to the left. But if there is not enough space to the left, the popover is not visible. > Proposed solution, for this situation, is to show the popover _above_ the cell. > The final position preference order will be (respect the cell): > RIGHT -> LEFT -> ABOVE > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4844) Alpha Network Compiler should be an option in Kie-API

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4844?page=com.atlassian.jira.plug... ] Luca Molteni reassigned DROOLS-4844: ------------------------------------ Assignee: Luca Molteni (was: Mario Fusco) > Alpha Network Compiler should be an option in Kie-API > ----------------------------------------------------- > > Key: DROOLS-4844 > URL: https://issues.redhat.com/browse/DROOLS-4844 > Project: Drools > Issue Type: Feature Request > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: good-first-issue > > In the `kie.internal` package extending `SingleValueKieBaseOption` > Currently it's a boolean in KieContainerImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4310) [DMN Designer] Data Types - Search - Replace the placeholder

by Stetson Robinson (Jira)

[ https://issues.redhat.com/browse/DROOLS-4310?page=com.atlassian.jira.plug... ] Stetson Robinson commented on DROOLS-4310: ------------------------------------------ [~jomarko], thanks. Sounds like will impact screenshots. Good to know. > [DMN Designer] Data Types - Search - Replace the placeholder > ------------------------------------------------------------ > > Key: DROOLS-4310 > URL: https://issues.redhat.com/browse/DROOLS-4310 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: karreiro > Assignee: Jozef Marko > Priority: Minor > Labels: drools-tools > Fix For: 7.31.0.Final > > > In the Data Types search input, replace the placeholder and use "Filter by". As illustrated at: https://www.patternfly.org/v3/pattern-library/content-views/list-view/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4674) Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path

by Honza Brázdil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4674?page=com.atlassian.jira.plug... ] Honza Brázdil commented on WFCORE-4674: --------------------------------------- any ETA on this? > Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4674 > URL: https://issues.redhat.com/browse/WFCORE-4674 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Labels: OpenShift, jdk11 > > If the log manager is on the boot class path with Java 11, {{-Xbootclasspath/a:jboss-logmanager.jar}}, and a custom handler, formatter or filter is used the server will fail to boot as the log manager can't see the types in jboss-modules. This seems due to the fact that the log manager is on the boot class path and jboss-modules is on the system class path. > Example exception: > {code} > Failed to read or configure the org.jboss.logmanager.LogManager > java.lang.IllegalArgumentException: Failed to load module "org.jboss.logmanager" for formatter "JSON" > at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:65) > at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30) > at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:172) > at org.jboss.logmanager.PropertyConfigurator.configureFormatter(PropertyConfigurator.java:631) > at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:701) > at org.jboss.logmanager.PropertyConfigurator.configureLogger(PropertyConfigurator.java:583) > at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:521) > at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97) > at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170) > at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132) > at java.util.logging.LogManager$3.run(LogManager.java:399) > at java.util.logging.LogManager$3.run(LogManager.java:396) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396) > at java.util.logging.LogManager.access$800(LogManager.java:145) > at java.util.logging.LogManager$2.run(LogManager.java:345) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338) > at java.util.logging.LogManager.getLogManager(LogManager.java:378) > at org.jboss.modules.Main.main(Main.java:523) > Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader > at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:556) > at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:63) > ... 19 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12854) Consider to allow non-resuable metrics of the same name in subdeployments

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12854?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12854: ------------------------------- Description: If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. * They are non-reusable: ** They are in the same deployment - ERROR is logged and metrics are not registerd ** They are in different deployments *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd Now I'd like to talk about the (X) option. This is valid for two scenarios: * Multiple deployments * Deployment with sub-deployments. In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric by a tag. However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. This is inconsistent behavior and it would be good to have it implemented. was: If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. * They are non-reusable: ** They are in the same deployment - ERROR is logged and metrics are not registerd ** They are in different deployments *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd Now I'd like to talk about the (X) option. This is valid for two scenarios: * Multiple deployments * Deployment with sub-deployments. In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. However I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric by a tag. However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. This is inconsistent behavior and it would be good to have it implemented. > Consider to allow non-resuable metrics of the same name in subdeployments > ------------------------------------------------------------------------- > > Key: WFLY-12854 > URL: https://issues.redhat.com/browse/WFLY-12854 > Project: WildFly > Issue Type: Feature Request > Components: MP Metrics > Reporter: Ivan Straka > Assignee: Jeff Mesnil > Priority: Major > > If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): > * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. > * They are non-reusable: > ** They are in the same deployment - ERROR is logged and metrics are not registerd > ** They are in different deployments > *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name > *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd > Now I'd like to talk about the (X) option. This is valid for two scenarios: > * Multiple deployments > * Deployment with sub-deployments. > In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric by a tag. > However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. > This is inconsistent behavior and it would be good to have it implemented. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12854) Consider to allow non-resuable metrics of the same name in subdeployments

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-12854?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-12854: ------------------------------- Description: If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. * They are non-reusable: ** They are in the same deployment - ERROR is logged and metrics are not registerd ** They are in different deployments *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd Now I'd like to talk about the (X) option. This is valid for two scenarios: * Multiple deployments * Deployment with sub-deployments. In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric using a tag. However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. This is inconsistent behavior and it would be good to have it implemented. was: If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. * They are non-reusable: ** They are in the same deployment - ERROR is logged and metrics are not registerd ** They are in different deployments *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd Now I'd like to talk about the (X) option. This is valid for two scenarios: * Multiple deployments * Deployment with sub-deployments. In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric by a tag. However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. This is inconsistent behavior and it would be good to have it implemented. > Consider to allow non-resuable metrics of the same name in subdeployments > ------------------------------------------------------------------------- > > Key: WFLY-12854 > URL: https://issues.redhat.com/browse/WFLY-12854 > Project: WildFly > Issue Type: Feature Request > Components: MP Metrics > Reporter: Ivan Straka > Assignee: Jeff Mesnil > Priority: Major > > If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): > * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. > * They are non-reusable: > ** They are in the same deployment - ERROR is logged and metrics are not registerd > ** They are in different deployments > *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name > *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd > Now I'd like to talk about the (X) option. This is valid for two scenarios: > * Multiple deployments > * Deployment with sub-deployments. > In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric using a tag. > However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. > This is inconsistent behavior and it would be good to have it implemented. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12854) Consider to allow non-resuable metrics of the same name in subdeployments

by Ivan Straka (Jira)

Ivan Straka created WFLY-12854: ---------------------------------- Summary: Consider to allow non-resuable metrics of the same name in subdeployments Key: WFLY-12854 URL: https://issues.redhat.com/browse/WFLY-12854 Project: WildFly Issue Type: Feature Request Components: MP Metrics Reporter: Ivan Straka Assignee: Jeff Mesnil If two method annotated to use MP Metrics have same name. In case of _Counters_ (example): * They are reusable there is actually one MP metric and both method invocation are counted to a single metric. * They are non-reusable: ** They are in the same deployment - ERROR is logged and metrics are not registerd ** They are in different deployments *** (X) MP Config _mp.metrics.appName_ is used thus metrics are registered under _configured_name;_app=the value_ thus they are registered under different name *** MP Config _mp.metrics.appName_ is not used - ERROR is logged and metrics are not registerd Now I'd like to talk about the (X) option. This is valid for two scenarios: * Multiple deployments * Deployment with sub-deployments. In Multiple deployments I am able to to annotate two methods with non-reusable metric of the same name. However I need to set MP Config _mp.metrics.appName_ property. Then I can select the metric by a tag. However per https://github.com/smallrye/smallrye-metrics/issues/216 I am not able to do that in deployment with sub-deployments scenario. This is inconsistent behavior and it would be good to have it implemented. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1023) Application Details - Pods and Error Rate Automate

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1023?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1023: ---------------------------------- Sprint: Kiali Sprint #30 > Application Details - Pods and Error Rate Automate > -------------------------------------------------- > > Key: SWSQE-1023 > URL: https://issues.redhat.com/browse/SWSQE-1023 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > > Besides health, it needs to automate the rest of health section fields. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1023) Application Details - Pods and Error Rate Automate

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1023?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1023: ------------------------------------- Assignee: Hayk Hovsepyan > Application Details - Pods and Error Rate Automate > -------------------------------------------------- > > Key: SWSQE-1023 > URL: https://issues.redhat.com/browse/SWSQE-1023 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Besides health, it needs to automate the rest of health section fields. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1025) Logs tab of Workload

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1025?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1025. ----------------------------------- Resolution: Done > Logs tab of Workload > -------------------- > > Key: SWSQE-1025 > URL: https://issues.redhat.com/browse/SWSQE-1025 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Automate Logs tab opening. > Containers. Pods. > Filters. > Textarea existence. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 December 2019