February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13112) Remove rbac-soak profile from org.wildfly:wildfly-ts-integ-mp

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13112: --------------------------------- Summary: Remove rbac-soak profile from org.wildfly:wildfly-ts-integ-mp Key: WFLY-13112 URL: https://issues.redhat.com/browse/WFLY-13112 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ingo Weiss Assignee: Darran Lofthouse Fix For: 19.0.0.Beta1 This appears to have come in inadvertently copying a structure from elsewhere in the testsuite. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12647) Remove rbac-soak profile from org.wildfly:wildfly-ts-integ-mp

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-12647?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFLY-12647: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/12698 > Remove rbac-soak profile from org.wildfly:wildfly-ts-integ-mp > ------------------------------------------------------------- > > Key: WFLY-12647 > URL: https://issues.redhat.com/browse/WFLY-12647 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 19.0.0.Beta1 > > > This appears to have come in inadvertently copying a structure from elsewhere in the testsuite. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13111) Workaround for MicroProfile Config TCK "ShouldThrowException" failure

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13111: --------------------------------- Summary: Workaround for MicroProfile Config TCK "ShouldThrowException" failure Key: WFLY-13111 URL: https://issues.redhat.com/browse/WFLY-13111 Project: WildFly Issue Type: Bug Components: MP Config Reporter: Ingo Weiss Assignee: Jeff Mesnil Fix For: 19.0.0.Beta2 Some MicroProfile Config TCK tests expects deployment failure by annotating the @Deployment with @ShouldThrowException(DeploymentException.class). Due to https://issues.redhat.com/browse/WFARQ-59, the deployment exception is not properly handled on the Arquillian client side and the test fails because, the thrown exception is not of the proper type. This can be worked around by adding a DeploymentExceptionTransformer that will transform the exception into the proper type. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13052) Workaround for MicroProfile Config TCK "ShouldThrowException" failure

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-13052?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFLY-13052: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/12957 > Workaround for MicroProfile Config TCK "ShouldThrowException" failure > --------------------------------------------------------------------- > > Key: WFLY-13052 > URL: https://issues.redhat.com/browse/WFLY-13052 > Project: WildFly > Issue Type: Bug > Components: MP Config > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 19.0.0.Beta2 > > > Some MicroProfile Config TCK tests expects deployment failure by annotating the @Deployment with @ShouldThrowException(DeploymentException.class). > Due to https://issues.redhat.com/browse/WFARQ-59, the deployment exception is not properly handled on the Arquillian client side and the test fails because, the thrown exception is not of the proper type. > This can be worked around by adding a DeploymentExceptionTransformer that will transform the exception into the proper type. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFLY-12952: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/12940 > MP Health returns UP when checks are expected but not installed yet. > -------------------------------------------------------------------- > > Key: WFLY-12952 > URL: https://issues.redhat.com/browse/WFLY-12952 > Project: WildFly > Issue Type: Bug > Components: MP Health > Affects Versions: 18.0.0.Final > Reporter: Ivan Straka > Assignee: Jeff Mesnil > Priority: Critical > Fix For: 19.0.0.Beta2 > > > MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says: > * A producer MUST support custom, application level health check procedures > * A producer SHOULD support reasonable out-of-the-box procedures > * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200) > * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503) > When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning. > _Let me note that on OpenShift starting the served should mean starting the service._ > Hence I expect negative overall status till the probe is ready and is able to provide response. > However WildFly with default setting responses with status UP: > {code:bash} > while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done > 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused > 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused > 17:17:56.466 {"status":"UP","checks":[]} > ... > 17:18:01.121 {"status":"UP","checks":[]} > 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]} > {code} > This violates (4) bullet in the specification. > WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...]) > Which would mean the scenario would behave according to the specification. Yet the default state violates it. > If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN: > {noformat} > 17:22:41.719 > {"status":"DOWN","checks":[]} > {noformat} > And that would violate (3) in the specification. > TCK tests do not cover the scenario well. > Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization. > If there is no deployment, the _UP_ it is. > Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because: > * OpenShift starts the service wait some time and start asking for health status > * WildFly responses _UP_ yet application helathcheck is not installed yet > * With health status _UP_ OpenShift consider a pod ready > * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13110) MP Health returns UP when checks are expected but not installed yet.

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13110: --------------------------------- Summary: MP Health returns UP when checks are expected but not installed yet. Key: WFLY-13110 URL: https://issues.redhat.com/browse/WFLY-13110 Project: WildFly Issue Type: Bug Components: MP Health Affects Versions: 18.0.0.Final Reporter: Ingo Weiss Assignee: Jeff Mesnil Fix For: 19.0.0.Beta2 MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says: * A producer MUST support custom, application level health check procedures * A producer SHOULD support reasonable out-of-the-box procedures * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200) * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503) When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning. _Let me note that on OpenShift starting the served should mean starting the service._ Hence I expect negative overall status till the probe is ready and is able to provide response. However WildFly with default setting responses with status UP: {code:bash} while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused 17:17:56.466 {"status":"UP","checks":[]} ... 17:18:01.121 {"status":"UP","checks":[]} 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]} {code} This violates (4) bullet in the specification. WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...]) Which would mean the scenario would behave according to the specification. Yet the default state violates it. If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN: {noformat} 17:22:41.719 {"status":"DOWN","checks":[]} {noformat} And that would violate (3) in the specification. TCK tests do not cover the scenario well. Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization. If there is no deployment, the _UP_ it is. Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because: * OpenShift starts the service wait some time and start asking for health status * WildFly responses _UP_ yet application helathcheck is not installed yet * With health status _UP_ OpenShift consider a pod ready * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13109) MicroProfile ConfigProviderResolver should be set eagerly

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13109: --------------------------------- Summary: MicroProfile ConfigProviderResolver should be set eagerly Key: WFLY-13109 URL: https://issues.redhat.com/browse/WFLY-13109 Project: WildFly Issue Type: Bug Components: MP Config Affects Versions: 18.0.1.Final Reporter: Ingo Weiss Assignee: Paul Ferraro Fix For: 19.0.0.Beta1 Consumers of MicroProfile Config should not have to depend on a service to ensure that the static value returned by ConfigProviderResolver.instance() is defined. A simple model requirement on the mp-config capability should be sufficient. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13108) microprofile-health subsystem should not expose smallrye implementation to deployments

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13108: --------------------------------- Summary: microprofile-health subsystem should not expose smallrye implementation to deployments Key: WFLY-13108 URL: https://issues.redhat.com/browse/WFLY-13108 Project: WildFly Issue Type: Bug Components: MP Config Affects Versions: 18.0.1.Final Reporter: Ingo Weiss Assignee: Paul Ferraro Fix For: 19.0.0.Beta1 Smallrye is an implementation detail of the specification and should not be exposed to deployments. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5073) menu didn't pop up when right-click the cell in decition table if there are lot of columns (more then 18)

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5073?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-5073: ---------------------------------------- This is fixed in 7.33.0.Final. I'll get the links etc when I go to the office. > menu didn't pop up when right-click the cell in decition table if there are lot of columns (more then 18) > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5073 > URL: https://issues.redhat.com/browse/DROOLS-5073 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.19.0.Final, 7.33.0.Final > Reporter: xiaodong zhang > Assignee: Michael Anstis > Priority: Major > Attachments: maycolumns.dmn > > > Menu didn't pop up when right-click the cell in decition table if there are lot of columns (more then 18). > This happened on my macbook pro. If I use a External display. The things will be better but still hit the issue if the columns is more than 25。 > But this isn't happend on my new windows machine(i7 9th , GTX1660ti) > So I guess this a a performance issue, when shortage of the hardware resource， the UI will refreshed when right click the cell and caused the right-click menu gone. > Please help to check this . Thanks a lot ! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5074) login is blocked when you create a group that name contains dot and assign some auth

by xiaodong zhang (Jira)

xiaodong zhang created DROOLS-5074: -------------------------------------- Summary: login is blocked when you create a group that name contains dot and assign some auth Key: DROOLS-5074 URL: https://issues.redhat.com/browse/DROOLS-5074 Project: Drools Issue Type: Bug Affects Versions: 7.33.0.Final, 7.19.0.Final Reporter: xiaodong zhang Assignee: Mario Fusco Attachments: image-2020-02-17-23-28-33-670.png, test.png login is blocked when you create a group that name contains dot and assign some auth, then save. and login out. Now every one can't login because of the attached error. -- 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 February 2020