February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13091) Upgrade HAL to 3.2.6.Final

by Harald Pehl (Jira)

[ https://issues.redhat.com/browse/WFLY-13091?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFLY-13091: ------------------------------- Description: This component upgrade contais bug fixes only. Diff: https://github.com/hal/console/compare/3.2.5.Final...3.2.7.Final was: This component upgrade contais bug fixes only. Diff: https://github.com/hal/console/compare/3.2.5.Final...3.2.6.Final > Upgrade HAL to 3.2.6.Final > -------------------------- > > Key: WFLY-13091 > URL: https://issues.redhat.com/browse/WFLY-13091 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 20.0.0.Beta1 > > > This component upgrade contais bug fixes only. > Diff: https://github.com/hal/console/compare/3.2.5.Final...3.2.7.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5066) First step to isolate Kafka deps

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5066?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-5066: --------------------------------------- Summary: First step to isolate Kafka deps (was: Introduce Interfaces to isolate Kafka API in the HACEP ) > First step to isolate Kafka deps > -------------------------------- > > Key: DROOLS-5066 > URL: https://issues.redhat.com/browse/DROOLS-5066 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > > Is a split of https://issues.redhat.com/browse/DROOLS-4706 to handle better in the review process -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5066) First step to isolate Kafka deps

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5066?page=com.atlassian.jira.plug... ] Massimiliano Dessi resolved DROOLS-5066. ---------------------------------------- Resolution: Done > First step to isolate Kafka deps > -------------------------------- > > Key: DROOLS-5066 > URL: https://issues.redhat.com/browse/DROOLS-5066 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > > Is a split of https://issues.redhat.com/browse/DROOLS-4706 to handle better in the review process -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13086) Upgrade gson from 2.8.2 to gson 2.8.6

by Bartosz Spyrko (Jira)

[ https://issues.redhat.com/browse/WFLY-13086?page=com.atlassian.jira.plugi... ] Bartosz Spyrko updated WFLY-13086: ---------------------------------- Summary: Upgrade gson from 2.8.2 to gson 2.8.6 (was: Upgrade gson from 2.8.2 to gson 2.8.5) > Upgrade gson from 2.8.2 to gson 2.8.6 > ------------------------------------- > > Key: WFLY-13086 > URL: https://issues.redhat.com/browse/WFLY-13086 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, MP OpenTracing > Reporter: Bartosz Spyrko > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: downstream_dependency > > Downstream dependency to align with Runtimes versions -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5083) Second step to isolate Kafka deps

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5083?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-5083: --------------------------------------- Sprint: 2020 Week 07-09 (from Feb 10) > Second step to isolate Kafka deps > --------------------------------- > > Key: DROOLS-5083 > URL: https://issues.redhat.com/browse/DROOLS-5083 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ] Fabio Burzigotti commented on WFWIP-306: ---------------------------------------- Thanks. I am setting up "old" tests and new ones to assess this new behavior. I'll get back when everything will be done from my side to cover this.. In the meantime, [~jmesnil], is there any pointer to community documentation about this change? Release Notes, Administration Guide, etc. > Health check response contains default readiness data > ----------------------------------------------------- > > Key: WFWIP-306 > URL: https://issues.redhat.com/browse/WFWIP-306 > Project: WildFly WIP > Issue Type: Bug > Components: MP Health > Reporter: Fabio Burzigotti > Assignee: Jeff Mesnil > Priority: Critical > > Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response. > When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name> > The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist. > This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284 > The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure. > 1. feature branch [1] > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > }, > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [ > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > {code} > 2. here are the results for the same calls against Wildfly 19 Beta 1: > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [] > } > {code} > [1] > https://github.com/jmesnil/wildfly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5083) Second step to isolate Kafka deps

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-5083: ------------------------------------------ Summary: Second step to isolate Kafka deps Key: DROOLS-5083 URL: https://issues.redhat.com/browse/DROOLS-5083 Project: Drools Issue Type: Task Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ] Jeff Mesnil commented on WFWIP-306: ----------------------------------- To be more clear, there is no change in overall status which is the most important thing to consider In both cases, the /health, /live and /ready endpoints all returns UP as expected. The only change is the inclusion of an additional readiness procedure that determines the overall /health and /ready statuses. If you want to use the previous payload, you have to set the mp.health.disable-default-procedures config property. > Health check response contains default readiness data > ----------------------------------------------------- > > Key: WFWIP-306 > URL: https://issues.redhat.com/browse/WFWIP-306 > Project: WildFly WIP > Issue Type: Bug > Components: MP Health > Reporter: Fabio Burzigotti > Assignee: Jeff Mesnil > Priority: Critical > > Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response. > When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name> > The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist. > This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284 > The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure. > 1. feature branch [1] > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > }, > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [ > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > {code} > 2. here are the results for the same calls against Wildfly 19 Beta 1: > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [] > } > {code} > [1] > https://github.com/jmesnil/wildfly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ] Jeff Mesnil edited comment on WFWIP-306 at 2/20/20 4:47 AM: ------------------------------------------------------------ This change is mentioned in the document: https://github.com/wildfly/wildfly-proposals/blob/dc28a32e484667452e5766f... It was added to fix WFLY-12952 that was done in 19.0.0.Beta2. It is *not* related to the MP Health 2.2 upgrade. was (Author: jmesnil): This change is mentioned in the document: https://github.com/wildfly/wildfly-proposals/blob/dc28a32e484667452e5766f... It was added to fix WFLY-12952 that was done in 19.0.0.Beta2. It is *not* related to the MP Health 2.2 upgrade. As documented in the WildFly documentation, you can set mp.health.disable-default-procedures to true to keep the previous behaviour > Health check response contains default readiness data > ----------------------------------------------------- > > Key: WFWIP-306 > URL: https://issues.redhat.com/browse/WFWIP-306 > Project: WildFly WIP > Issue Type: Bug > Components: MP Health > Reporter: Fabio Burzigotti > Assignee: Jeff Mesnil > Priority: Critical > > Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response. > When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name> > The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist. > This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284 > The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure. > 1. feature branch [1] > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > }, > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [ > { > "name": "ready-deployment.HealthTest.war", > "status": "UP" > } > ] > } > {code} > 2. here are the results for the same calls against Wildfly 19 Beta 1: > {code} > //health > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //live > { > "status": "UP", > "checks": [ > { > "name": "live", > "status": "UP", > "data": { > "key": "value" > } > } > ] > } > //ready > { > "status": "UP", > "checks": [] > } > {code} > [1] > https://github.com/jmesnil/wildfly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4800) [DMN Designer] Add support for copy and paste in grids

by Donato Marrazzo (Jira)

[ https://issues.redhat.com/browse/DROOLS-4800?page=com.atlassian.jira.plug... ] Donato Marrazzo commented on DROOLS-4800: ----------------------------------------- I think this requirement is really important. In day by day, it's really common to refactor the model. For example, today, I need to move a decision table from a context to another context. ATM, there is no way to select a group of cells or the entire decision table. Maybe a good idea could be to add a visual handle to select the whole table, whereas the SHIFT+click should be used to select a cell group (square box of cells). > [DMN Designer] Add support for copy and paste in grids > ------------------------------------------------------ > > Key: DROOLS-4800 > URL: https://issues.redhat.com/browse/DROOLS-4800 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > Add support for copying/pasting between cells in grids. > The implementation should re-use and integrate with the existing Stunner mechanism (i.e. if there are toolbar buttons to copy/paste nodes they should be re-used to copy/paste cells when in the grid view. Copying a grid cell(s) should probably replace any _node_ content on the virtual clipboard and vice-versa. In addition to toolbar buttons the feature should probably be also exposed on a context-menu and keyboard short-cuts... > Pasting a cell into another should only be possible where the type of cell is compatible. I.E. you cannot paste an expression cell (e.g. nested Decision Table on a ContextEntry) into a literal cell (e.g. Relation grid cell). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 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 February 2020