July 2020 - jboss-jira - Jboss List Archives

[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)

5 years, 5 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)

5 years, 5 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)

5 years, 5 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)

5 years, 5 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)

5 years, 5 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)

5 years, 5 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)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5475) Externalize lambda for rule attributes

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5475: ----------------------------------------- Summary: Externalize lambda for rule attributes Key: DROOLS-5475 URL: https://issues.redhat.com/browse/DROOLS-5475 Project: Drools Issue Type: Sub-task Components: executable model Affects Versions: 7.39.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi lambdas for dynamic rule attributes are not externalized. e.g. RuleAttributesTest#testDynamicSalience -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5474) Externalize lambda for conditional and named consequences

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5474: ----------------------------------------- Summary: Externalize lambda for conditional and named consequences Key: DROOLS-5474 URL: https://issues.redhat.com/browse/DROOLS-5474 Project: Drools Issue Type: Sub-task Components: executable model Affects Versions: 7.39.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi lambdas for "if" conditional elements are not externalized. e.g. NamedConsequencesTest#testBreakingNamedConsequence -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5473) Implement DefineFunction scheleton

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5473: ---------------------------------------- Summary: Implement DefineFunction scheleton Key: DROOLS-5473 URL: https://issues.redhat.com/browse/DROOLS-5473 Project: Drools Issue Type: Sub-task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Implement DefineFunction management scheleton. DefineFunctions are similar to DerivedFields, since both make usage of EXPRESSION. Differences are 1) DerivedFields methods should referenced inside "transformations" map, DefineFunctions not 2) DerivedFields methods names are automatically generated, while DefineFunctions ones are retrieved from DefinedFunctions declaration 3) DefineFunctions requires at least one Parameter (beside the List of already defined fields ) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020