December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFCORE-5212) Remove Phase PARSE_EE_DEFAULT_BINDINGS_CONFIG

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5212: ---------------------------------------- Summary: Remove Phase PARSE_EE_DEFAULT_BINDINGS_CONFIG Key: WFCORE-5212 URL: https://issues.redhat.com/browse/WFCORE-5212 Project: WildFly Core Issue Type: Task Components: Server Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 14.0.0.Beta3 This has been moved to STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5211) Add new Phases for base metrics and health subsystems

by Jeff Mesnil (Jira)

Jeff Mesnil created WFCORE-5211: ----------------------------------- Summary: Add new Phases for base metrics and health subsystems Key: WFCORE-5211 URL: https://issues.redhat.com/browse/WFCORE-5211 Project: WildFly Core Issue Type: Task Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil New metrics and health subsystems (tracked by WFLY-14108 & WFLY-14151) needs distinct Phases from the existing microprofile-metrics-smallrye & microprofile-health-smallry. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5210) Add a new Phase ID STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5210?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-5210: ------------------------------------- Description: {code:java} public static final int STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG = 0x1B10; {code} > Add a new Phase ID STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG > ------------------------------------------------------- > > Key: WFCORE-5210 > URL: https://issues.redhat.com/browse/WFCORE-5210 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 14.0.0.Beta3 > > > {code:java} > public static final int STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG = 0x1B10; {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5210) Add a new Phase ID STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5210: ---------------------------------------- Summary: Add a new Phase ID STRUCTURE_EE_DEFAULT_BINDINGS_CONFIG Key: WFCORE-5210 URL: https://issues.redhat.com/browse/WFCORE-5210 Project: WildFly Core Issue Type: Task Components: Server Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 14.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1037) OC API - Service Endpoints read

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1037?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1037: ------------------------------------- Assignee: Hayk Hovsepyan > OC API - Service Endpoints read > ------------------------------- > > Key: SWSQE-1037 > URL: https://issues.redhat.com/browse/SWSQE-1037 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1208) UI Automations - Fix random failures

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1208?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1208: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/361 > UI Automations - Fix random failures > ------------------------------------ > > Key: SWSQE-1208 > URL: https://issues.redhat.com/browse/SWSQE-1208 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/run-kiali-ui-te... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1037) OC API - Service Endpoints read

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1037?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1037: ---------------------------------- Sprint: Kiali Sprint #49 > OC API - Service Endpoints read > ------------------------------- > > Key: SWSQE-1037 > URL: https://issues.redhat.com/browse/SWSQE-1037 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-2687) Expose the current step operation's name and parameters via the OperationContext

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-2687?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-2687: ------------------------------------- Description: Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. The getCurrentOperationParameter should reject 'operation', 'address', 'operation-headers' etc as legal param names; only expose true parameters. EDIT: I removed 'name' from the list of illegal param names. It's not a special key in an operation model node. I added 'operation', which is a special key. I suspect when I wrote this I confused myself because the value of 'operation' key is the name of the operation. was: Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. The getCurrentOperationParameter should reject 'address', 'operation-headers' etc as legal param names; only expose true parameters. EDIT: I removed 'name' from the list of illegal param names. It's not a special key in an operation model node. > Expose the current step operation's name and parameters via the OperationContext > -------------------------------------------------------------------------------- > > Key: WFCORE-2687 > URL: https://issues.redhat.com/browse/WFCORE-2687 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Lukas Vydra > Priority: Major > > Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. > OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). > The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. > The getCurrentOperationParameter should reject 'operation', 'address', 'operation-headers' etc as legal param names; only expose true parameters. > EDIT: I removed 'name' from the list of illegal param names. It's not a special key in an operation model node. I added 'operation', which is a special key. I suspect when I wrote this I confused myself because the value of 'operation' key is the name of the operation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-2687) Expose the current step operation's name and parameters via the OperationContext

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-2687?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-2687: ------------------------------------- Description: Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. The getCurrentOperationParameter should reject 'address', 'operation-headers' etc as legal param names; only expose true parameters. EDIT: I removed 'name' from the list of illegal param names. It's not a special key in an operation model node. was: Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. The getCurrentOperationParameter should reject 'name', 'address', 'operation-headers' etc as legal param names; only expose true parameters. > Expose the current step operation's name and parameters via the OperationContext > -------------------------------------------------------------------------------- > > Key: WFCORE-2687 > URL: https://issues.redhat.com/browse/WFCORE-2687 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Lukas Vydra > Priority: Major > > Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. > OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). > The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. > The getCurrentOperationParameter should reject 'address', 'operation-headers' etc as legal param names; only expose true parameters. > EDIT: I removed 'name' from the list of illegal param names. It's not a special key in an operation model node. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (LOGMGR-282) The SyslogHandler should use the PID from the log record

by James Perkins (Jira)

James Perkins created LOGMGR-282: ------------------------------------ Summary: The SyslogHandler should use the PID from the log record Key: LOGMGR-282 URL: https://issues.redhat.com/browse/LOGMGR-282 Project: JBoss Log Manager Issue Type: Task Reporter: James Perkins Assignee: James Perkins LOGMGR-152 introduced some new fields in the {{ExtLogRecord}}. The {{SyslogHandler}} uses it's own PID. However this should be retrieved from the log record instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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