March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13287) Sync version of arquillian-testng-container with arquillian-junit-container

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13287: ----------------------------------- Summary: Sync version of arquillian-testng-container with arquillian-junit-container Key: WFLY-13287 URL: https://issues.redhat.com/browse/WFLY-13287 Project: WildFly Issue Type: Component Upgrade Components: MP OpenAPI, Test Suite Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13054) Upgrade FasterXML Jackson2 to 2.10.3

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13054?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13054: --------------------------------------- Fix Version/s: 20.0.0.Beta1 Assignee: Panagiotis Sotiropoulos (was: Ivo Studensky) Resolution: Done > Upgrade FasterXML Jackson2 to 2.10.3 > ------------------------------------ > > Key: WFLY-13054 > URL: https://issues.redhat.com/browse/WFLY-13054 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Panagiotis Sotiropoulos > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13269) The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13269?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13269: ------------------------------------ [~jamezp] yes, I've added it. > The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension > ------------------------------------------------------------------------------------------ > > Key: WFLY-13269 > URL: https://issues.redhat.com/browse/WFLY-13269 > Project: WildFly > Issue Type: Bug > Components: Build System, MP JWT, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 20.0.0.Beta1 > > > This means if the artefact is included in a deployment the JWT activation is incorrectly triggered but with some dependencies missing leading to an error such as the following. > {code} > 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension > at java.lang.ClassLoader.defineClass1(ClassLoader.java) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2462 at 3/25/20 12:28 PM: ---------------------------------------------------------- Protocols such as RED or Blue (\[2\]) have to know the queue's capacity and the current size, e.g. to maintain an average size, which is used to compute the probability with which a message is dropped. The capacity is fixed and can be fetched via {{TP.getBundlerCapacity()}}. Seems like adding {{getQueueSize()}} to {{Bundler}} would allow us to implement random early detection in a separate protocol (e.g. {{RED}}). This is *not* the same as {{Bundler.size()}}; we cannot use the latter as it returns the total number of _unsent_ messages. \[2\\ https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm) was (Author: belaban): Protocols such as RED or Blue (\[2\]) have to know the queue's capacity and the current size, e.g. to maintain an average size, which is used to compute the probability with which a message is dropped. Seems like adding {{getQueueSize()}} to {{Bundler}} would allow us to implement random early detection in a separate protocol (e.g. {RED}}). This is *not* the same as {{Bundler.size()}}; we cannot use the latter as it returns the total number of _unsent_ messages. \[2\\ https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm) > TransferQueueBundler: drop messages if queue is full > ---------------------------------------------------- > > Key: JGRP-2462 > URL: https://issues.redhat.com/browse/JGRP-2462 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block. > This can happen for example when the TCP {{send}} blocks due to a full send-window. > Retransmission requests and responses compound the problem when the TQB's queue is full. > Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first. > Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter. > Look at random early detection )\[1\]) for inspiration. > \[1\] https://en.wikipedia.org/wiki/Random_early_detection -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2462 at 3/25/20 12:28 PM: ---------------------------------------------------------- Protocols such as RED or Blue (\[2\]) have to know the queue's capacity and the current size, e.g. to maintain an average size, which is used to compute the probability with which a message is dropped. The capacity is fixed and can be fetched via {{TP.getBundlerCapacity()}}. Seems like adding {{getQueueSize()}} to {{Bundler}} would allow us to implement random early detection in a separate protocol (e.g. {{RED}}). This is *not* the same as {{Bundler.size()}}; we cannot use the latter as it returns the total number of _unsent_ messages. \[2\] https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm) was (Author: belaban): Protocols such as RED or Blue (\[2\]) have to know the queue's capacity and the current size, e.g. to maintain an average size, which is used to compute the probability with which a message is dropped. The capacity is fixed and can be fetched via {{TP.getBundlerCapacity()}}. Seems like adding {{getQueueSize()}} to {{Bundler}} would allow us to implement random early detection in a separate protocol (e.g. {{RED}}). This is *not* the same as {{Bundler.size()}}; we cannot use the latter as it returns the total number of _unsent_ messages. \[2\\ https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm) > TransferQueueBundler: drop messages if queue is full > ---------------------------------------------------- > > Key: JGRP-2462 > URL: https://issues.redhat.com/browse/JGRP-2462 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block. > This can happen for example when the TCP {{send}} blocks due to a full send-window. > Retransmission requests and responses compound the problem when the TQB's queue is full. > Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first. > Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter. > Look at random early detection )\[1\]) for inspiration. > \[1\] https://en.wikipedia.org/wiki/Random_early_detection -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-3580?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-3580: ----------------------------------- Sprint: 2020 Week 13-15 (from Mar 23) > [DMN Designer] Decision Table: Add support for merged view > ---------------------------------------------------------- > > Key: DROOLS-3580 > URL: https://issues.redhat.com/browse/DROOLS-3580 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Edson Tirelli > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > Add support for viewing the {{DecisionTableGrid}} in _merged_ mode. > The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged.. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4770) Design review/recommendations for Decision Table merged view

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4770?page=com.atlassian.jira.plug... ] Michael Anstis reassigned DROOLS-4770: -------------------------------------- Assignee: Elizabeth Clayton > Design review/recommendations for Decision Table merged view > ------------------------------------------------------------ > > Key: DROOLS-4770 > URL: https://issues.redhat.com/browse/DROOLS-4770 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Minor > Labels: UX, UXTeam, drools-tools > > Review the visual presentation of the {{DecisionTableGrid}} in _merged_ mode, to access usability enhancements. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5194) [DMN Designer] List: Remove header

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5194?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-5194: ----------------------------------- Attachment: BC.png BC-nested.png > [DMN Designer] List: Remove header > ---------------------------------- > > Key: DROOLS-5194 > URL: https://issues.redhat.com/browse/DROOLS-5194 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.34.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Fix For: 7.36.0.Final > > Attachments: BC-nested.png, BC.png, VSCode-nested.png, VSCode.png > > > Further to DROOLS-5131 it is incorrect for the {{List}} to have any header. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2462: -------------------------------- Protocols such as RED or Blue (\[2\]) have to know the queue's capacity and the current size, e.g. to maintain an average size, which is used to compute the probability with which a message is dropped. Seems like adding {{getQueueSize()}} to {{Bundler}} would allow us to implement random early detection in a separate protocol (e.g. {RED}}). This is *not* the same as {{Bundler.size()}}; we cannot use the latter as it returns the total number of _unsent_ messages. \[2\\ https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm) > TransferQueueBundler: drop messages if queue is full > ---------------------------------------------------- > > Key: JGRP-2462 > URL: https://issues.redhat.com/browse/JGRP-2462 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block. > This can happen for example when the TCP {{send}} blocks due to a full send-window. > Retransmission requests and responses compound the problem when the TQB's queue is full. > Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first. > Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter. > Look at random early detection )\[1\]) for inspiration. > \[1\] https://en.wikipedia.org/wiki/Random_early_detection -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5194) [DMN Designer] List: Remove header

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5194?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-5194: ----------------------------------- Attachment: VSCode.png VSCode-nested.png > [DMN Designer] List: Remove header > ---------------------------------- > > Key: DROOLS-5194 > URL: https://issues.redhat.com/browse/DROOLS-5194 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.34.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Fix For: 7.36.0.Final > > Attachments: VSCode-nested.png, VSCode.png > > > Further to DROOLS-5131 it is incorrect for the {{List}} to have any header. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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 March 2020