July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5028) CallbackHandler from CLI overriding discovered wildfly-config for authentication.

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5028: ---------------------------------------- Summary: CallbackHandler from CLI overriding discovered wildfly-config for authentication. Key: WFCORE-5028 URL: https://issues.redhat.com/browse/WFCORE-5028 Project: WildFly Core Issue Type: Bug Components: CLI, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 12.0.2.Final, 13.0.0.Beta2 WFCORE-4976 made an update to ProtocolConnectionUtils so that a supplied CallbackHandler takes priority - this works where a client is using ModelControllerClient.create() and passing in a CallbackHandler as we should take that as an indication that the caller wants control of authentication. However by fixing in ProtocolConnectionUtils it has also picked up the case where the CLI passes in the CallbackHandler - that case however should only use the CBH if the information can not be obtained from the AuthenticationConfiguration. This call does not come via ModelControllerClient but both paths meet at ProtocolConnectionUtils. Either the adjustment of the AuthenticationContext to give the CallbackHandler should happen in ModelControllerClient - or an additional boolean should be passed into ProtocolConnectionUtils to indicate if the CallbackHandler should be given priority. The latter may be a less invasive evolution of the fix prepared so far. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13640) Provide Support for MicroProfile Reactive Messaging

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFLY-13640?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFLY-13640: ------------------------------ Description: This currently lives in [https://github.com/wildfly-extras/wildfly-mp-reactive-feature-pack]. Investigate stability and readiness for inclusion in WildFly. This may be using the upcoming feature-pack artifact dependency mechanism was: Sending and receiving messages between microservices with MicroProfile Reactive Messaging specification. It will possible to produce, process and consume messages within your application. Smallrye Reactive Messaging: https://smallrye.io/smallrye-reactive-messaging/ > Provide Support for MicroProfile Reactive Messaging > --------------------------------------------------- > > Key: WFLY-13640 > URL: https://issues.redhat.com/browse/WFLY-13640 > Project: WildFly > Issue Type: Feature Request > Reporter: Bilgehan Ozpeynirci > Assignee: Kabir Khan > Priority: Major > > This currently lives in [https://github.com/wildfly-extras/wildfly-mp-reactive-feature-pack]. Investigate stability and readiness for inclusion in WildFly. This may be using the upcoming feature-pack artifact dependency mechanism > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13640) Provide Support for MicroProfile Reactive Messaging

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFLY-13640?page=com.atlassian.jira.plugi... ] Kabir Khan moved EAP7-1519 to WFLY-13640: ----------------------------------------- Project: WildFly (was: JBoss EAP Planning for version 7 and above) Key: WFLY-13640 (was: EAP7-1519) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: (was: MicroProfile) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: EAP-XP-2.0.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) > Provide Support for MicroProfile Reactive Messaging > --------------------------------------------------- > > Key: WFLY-13640 > URL: https://issues.redhat.com/browse/WFLY-13640 > Project: WildFly > Issue Type: Feature Request > Reporter: Bilgehan Ozpeynirci > Assignee: Kabir Khan > Priority: Major > > Sending and receiving messages between microservices with MicroProfile Reactive Messaging specification. > It will possible to produce, process and consume messages within your application. > Smallrye Reactive Messaging: https://smallrye.io/smallrye-reactive-messaging/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4976) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4976?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4976: ------------------------------------- Component/s: (was: CLI) > Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4976 > URL: https://issues.redhat.com/browse/WFCORE-4976 > Project: WildFly Core > Issue Type: Bug > Components: Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta4, 12.0.0.Final > > > In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: - > {code:java} > if (handler != null) { > mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS); > } > {code} > However the AuthenticationClient performs the following sanitation of the specified KINDS: - > {code:java} > case SET_USER_CB_KINDS: > // SANITAZE on above content > if (this.principal != null) { > sanitazeOnMutation(SET_PRINCIPAL); > } > if (this.credentialSource != null) { > sanitazeOnMutation(SET_CRED_SOURCE); > } > if (this.setRealm != null) { > sanitazeOnMutation(SET_REALM); > } > if (this.parameterSpecs != null) { > sanitazeOnMutation(SET_PARAM_SPECS); > } > if (this.keyManagerFactory != null) { > sanitazeOnMutation(SET_KEY_MGR_FAC); > } > break; > {code} > Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4976) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4976?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4976: ------------------------------------- Component/s: Management > Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4976 > URL: https://issues.redhat.com/browse/WFCORE-4976 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta4, 12.0.0.Final > > > In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: - > {code:java} > if (handler != null) { > mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS); > } > {code} > However the AuthenticationClient performs the following sanitation of the specified KINDS: - > {code:java} > case SET_USER_CB_KINDS: > // SANITAZE on above content > if (this.principal != null) { > sanitazeOnMutation(SET_PRINCIPAL); > } > if (this.credentialSource != null) { > sanitazeOnMutation(SET_CRED_SOURCE); > } > if (this.setRealm != null) { > sanitazeOnMutation(SET_REALM); > } > if (this.parameterSpecs != null) { > sanitazeOnMutation(SET_PARAM_SPECS); > } > if (this.keyManagerFactory != null) { > sanitazeOnMutation(SET_KEY_MGR_FAC); > } > break; > {code} > Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4976) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4976?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4976: ------------------------------------- Component/s: CLI (was: Management) > Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4976 > URL: https://issues.redhat.com/browse/WFCORE-4976 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta4, 12.0.0.Final > > > In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: - > {code:java} > if (handler != null) { > mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS); > } > {code} > However the AuthenticationClient performs the following sanitation of the specified KINDS: - > {code:java} > case SET_USER_CB_KINDS: > // SANITAZE on above content > if (this.principal != null) { > sanitazeOnMutation(SET_PRINCIPAL); > } > if (this.credentialSource != null) { > sanitazeOnMutation(SET_CRED_SOURCE); > } > if (this.setRealm != null) { > sanitazeOnMutation(SET_REALM); > } > if (this.parameterSpecs != null) { > sanitazeOnMutation(SET_PARAM_SPECS); > } > if (this.keyManagerFactory != null) { > sanitazeOnMutation(SET_KEY_MGR_FAC); > } > break; > {code} > Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2478) Fibers: test performance versus regular threads

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2478?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2478: --------------------------- Description: Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. This requires a few code changes: * There's no need to pool fibers, see [1] for details * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThreadExecutor()}} * In a future version, we could simply remove the 2 thread pools [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] was: Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. This requires a few code changes: * There's no need to pool fibers, see [1] for details * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThreadExecutor()}} * In a future version, we could simply remove the 2 thread pool [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] > Fibers: test performance versus regular threads > ----------------------------------------------- > > Key: JGRP-2478 > URL: https://issues.redhat.com/browse/JGRP-2478 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Final > > > Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. > This requires a few code changes: > * There's no need to pool fibers, see [1] for details > * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThreadExecutor()}} > * In a future version, we could simply remove the 2 thread pools > [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2478) Fibers: test performance versus regular threads

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2478?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2478: --------------------------- Description: Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. This requires a few code changes: * There's no need to pool fibers, see [1] for details * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThreadExecutor()}} * In a future version, we could simply remove the 2 thread pool [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] was: Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. This requires a few code changes: * There's no need to pool fibers, see [1] for details * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThradExecutor()}} * In a future version, we could simply remove the 2 thread pool [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] > Fibers: test performance versus regular threads > ----------------------------------------------- > > Key: JGRP-2478 > URL: https://issues.redhat.com/browse/JGRP-2478 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Final > > > Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. > This requires a few code changes: > * There's no need to pool fibers, see [1] for details > * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThreadExecutor()}} > * In a future version, we could simply remove the 2 thread pool > [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2478) Fibers: test performance versus regular threads

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2478?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2478: --------------------------- Description: Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. This requires a few code changes: * There's no need to pool fibers, see [1] for details * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThradExecutor()}} * In a future version, we could simply remove the 2 thread pool [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] was:Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}} > Fibers: test performance versus regular threads > ----------------------------------------------- > > Key: JGRP-2478 > URL: https://issues.redhat.com/browse/JGRP-2478 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Final > > > Test performance on the latest JDK-15-loom with {{use_fibers="true"/"false"}}. > This requires a few code changes: > * There's no need to pool fibers, see [1] for details > * If fibers are used, {{thread_pool}} and {{internal_pool}} in {{TP}} could be assigned the result of {{Executors.newVirtualThradExecutor()}} > * In a future version, we could simply remove the 2 thread pool > [1] [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Michael Musgrove commented on WFLY-13633: ----------------------------------------- Okay I see the issue. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020