May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from POST to MODIFIED > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2888) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2888?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2888: ------------------------------- Issue Type: Component Upgrade (was: Bug) > Upgrade CLI to use aesh 0.66.18 and jansi 1.16 > ---------------------------------------------- > > Key: WFCORE-2888 > URL: https://issues.jboss.org/browse/WFCORE-2888 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Today jansi 1.11 breaks the rule of being source code 1.6. > jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2889) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-2889: ---------------------------------- Summary: Upgrade CLI to use aesh 0.66.18 and jansi 1.16 Key: WFCORE-2889 URL: https://issues.jboss.org/browse/WFCORE-2889 Project: WildFly Core Issue Type: Component Upgrade Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Today jansi 1.11 breaks the rule of being source code 1.6. jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2888) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2888: -------------------------------------------- Summary: Upgrade CLI to use aesh 0.66.18 and jansi 1.16 Key: WFCORE-2888 URL: https://issues.jboss.org/browse/WFCORE-2888 Project: WildFly Core Issue Type: Bug Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Today jansi 1.11 breaks the rule of being source code 1.6. jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2880) remove-alias should fail when remove non-existent alias from credential store.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2880?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2880: ------------------------------------------ IMHO it's debatable whether this is a bug. I can see both sides of it, and for something like this where a typo in what you are removing can result in leaving something behind there's a stronger case for being strict. In general though it's quite normal for APIs to allow people to try and remove things that may not exist, since the user may not care if the thing was there, so long as it's no longer there at the end. This also needs to consider things like the use of this operation on a /profile=x/subsystem=elytron/... resource, as that may increase the odds of the thing not being there on a particular server and the user being fine with that. > remove-alias should fail when remove non-existent alias from credential store. > ------------------------------------------------------------------------------ > > Key: WFCORE-2880 > URL: https://issues.jboss.org/browse/WFCORE-2880 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > remove-alias should fail when remove non-existent alias from credential store. > There is expected fail when we try to remove non-existent alias from credential store. > *How to reproduce* > *create credential store* > {code} > /subsystem=elytron/credential-store=cs001:add(create=true, credential-reference={clear-text=pass123},location=cs001.jceks) > {code} > *Try to remove alias from empty credential store* > {code} > /subsystem=elytron/credential-store=cs001:remove-alias(alias=alias001) > { > "outcome" => "success", > "result" => undefined > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2885: ------------------------------------------ Yes, we're not exactly consistent. For sure for this one I don't want to fail as this is a general purpose API that should work like java.util.Collection.remove. An enhancement request to return true/false depending on whether something was removed would be reasonable though. For other remove-xxx one off operations, they are not general purpose so there's more scope for arguing that they should fail given the context of the op. For example WFCORE-2880 involves a security object. > list-remove operation succeeds when removing non-existent item > -------------------------------------------------------------- > > Key: WFCORE-2885 > URL: https://issues.jboss.org/browse/WFCORE-2885 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Petrov > Assignee: Michal Petrov > > When removing an item from a list the operation should fail if the item doesn't exist. E.g. > {code} > /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC") > {code} > the operation already fails when using an invalid index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2886: --------------------------------------- Scratch that, I read it wrong. Sorry not the resource the handler itself does not exist. I guess not failing, the current behavior, makes the most sense really. Having it fail could potentially break scripts. I don't *think* a user could care if the handler didn't exist they're trying to remove. The end goal is to not have the handler in the list and that is accomplished if the handler doesn't exist. > remove-handler operation succeeds when removing non-existent handler > -------------------------------------------------------------------- > > Key: WFCORE-2886 > URL: https://issues.jboss.org/browse/WFCORE-2886 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Michal Petrov > Assignee: Michal Petrov > > When trying to remove a handler that doesn't exist the operation should fail. E.g. > {code} > /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2886: --------------------------------------- Unless I'm missing something this already fails in WildFly Core: {code} [standalone@localhost:9990 /] /subsystem=logging/root-logger=ROOT:remove-handler(name=FILE) { "outcome" => "failed", "failure-description" => "WFLYCTL0216: Management resource '[ (\"subsystem\" => \"logging\"), (\"root-logger\" => \"ROOT\") ]' not found", "rolled-back" => true } {code} > remove-handler operation succeeds when removing non-existent handler > -------------------------------------------------------------------- > > Key: WFCORE-2886 > URL: https://issues.jboss.org/browse/WFCORE-2886 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Michal Petrov > Assignee: Michal Petrov > > When trying to remove a handler that doesn't exist the operation should fail. E.g. > {code} > /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ] Jan Kalina reopened ELY-1151: ----------------------------- > Empty authorization name for Digest mechanism causes authentication fail > ------------------------------------------------------------------------ > > Key: ELY-1151 > URL: https://issues.jboss.org/browse/ELY-1151 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta44 > > > SASL specification says about Authorization Identity String [1]: > {quote} > If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.* > {quote} > In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string. > It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name. > It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail. > The same issue can occurs for every supported SASL mechanism. In needs to be revisited. > We request blocker flag since current behavior violates SASL specification. > [1] https://tools.ietf.org/html/rfc4422#section-3.4.1 > [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFCORE-2885: --------------------------------------- As I said there are some remove-* operations that do fail (e.g. "remove-namespace") and some that don't. With WFCORE-2880 filed I wasn't sure what is the intended behavior of these. > list-remove operation succeeds when removing non-existent item > -------------------------------------------------------------- > > Key: WFCORE-2885 > URL: https://issues.jboss.org/browse/WFCORE-2885 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Petrov > Assignee: Michal Petrov > > When removing an item from a list the operation should fail if the item doesn't exist. E.g. > {code} > /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC") > {code} > the operation already fails when using an invalid index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 11 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 May 2017