February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-903: -------------------------------- Resolved by replacing depth first search (using recursion) by breadth first search (using queue and cycle). > Missing some role assignment for Elytron ldap-realm when role and user are members of the same role > --------------------------------------------------------------------------------------------------- > > Key: ELY-903 > URL: https://issues.jboss.org/browse/ELY-903 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > Attachments: print-roles.war > > > In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration. > Most important part of ldif for reproduction is following: > {code} > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: uid=jduke,ou=People,dc=jboss,dc=org > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing). > The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1303) OOPath reactive Collection coverage

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1303?page=com.atlassian.jira.plugi... ] Matteo Mortari resolved DROOLS-1303. ------------------------------------ Fix Version/s: 7.0.0.Beta5 Resolution: Done Done with: * https://github.com/droolsjbpm/drools/commit/20611a8ecac04da5034ce08d04520... * https://github.com/droolsjbpm/droolsjbpm-integration/commit/a02acc8888817... * https://github.com/droolsjbpm/kie-docs/commit/9c1296ac29a1ac7a18aade711a4... > OOPath reactive Collection coverage > ----------------------------------- > > Key: DROOLS-1303 > URL: https://issues.jboss.org/browse/DROOLS-1303 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.CR2 > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 7.0.0.Beta5 > > > * proper coverage for all methods of java.util.Collection e.g.: addAll() -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1312) Maven plug-in to auto instrument bytecode for OOPath reactivity

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1312?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1312: ---------------------------------------- This was documented with https://github.com/droolsjbpm/kie-docs/commit/9c1296ac29a1ac7a18aade711a4... > Maven plug-in to auto instrument bytecode for OOPath reactivity > --------------------------------------------------------------- > > Key: DROOLS-1312 > URL: https://issues.jboss.org/browse/DROOLS-1312 > Project: Drools > Issue Type: Feature Request > Components: tools > Affects Versions: 6.5.0.CR2 > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > Fix For: 7.0.0.Beta3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations

by Markus Pollak (JIRA)

[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ] Markus Pollak commented on JBEE-171: ------------------------------------ The solution is fine. > Java EE 7 API: unable to validate expressions with method invocations > --------------------------------------------------------------------- > > Key: JBEE-171 > URL: https://issues.jboss.org/browse/JBEE-171 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jsf-api > Reporter: Markus Pollak > Assignee: Dmitrii Tikhomirov > > Hello, > I’ve found a bug in the javaee-api-7.0.jar: > *Problem:* > javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems… > Best Regards, > Markus Pollak -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ] Tomas Hofman commented on WFLY-4748: ------------------------------------ [~bvnghiem1012] you will have to use Wildfly 10 to have this fixed. > Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1" > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4748 > URL: https://issues.jboss.org/browse/WFLY-4748 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: Tomas Hofman > Assignee: Paul Ferraro > Fix For: 10.0.0.Alpha6 > > > When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1". > This only happens after the second and other successive splits. After the first split both nodes execute the service correctly. > After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'. > I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted(): > {code} > public void viewAccepted(View view) { > // ... > for (Listener listener: this.listeners) { > listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView); > } > } > {code} > This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"

by Bui Van Nghiem (JIRA)

[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ] Bui Van Nghiem commented on WFLY-4748: -------------------------------------- https://github.com/wildfly/wildfly/pull/7685 is not merged to 9.x branch > Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1" > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4748 > URL: https://issues.jboss.org/browse/WFLY-4748 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: Tomas Hofman > Assignee: Paul Ferraro > Fix For: 10.0.0.Alpha6 > > > When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1". > This only happens after the second and other successive splits. After the first split both nodes execute the service correctly. > After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'. > I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted(): > {code} > public void viewAccepted(View view) { > // ... > for (Listener listener: this.listeners) { > listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView); > } > } > {code} > This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"

by Bui Van Nghiem (JIRA)

[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ] Bui Van Nghiem edited comment on WFLY-4748 at 2/8/17 10:46 PM: --------------------------------------------------------------- I still face the same error on WildFly 9.0.2 after Full GC on master server: 2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "my-service" service. No singleton master will be elected. was (Author: bvnghiem1012): I still face the same error on WildFly 9.0.2 after Full GC on master server: 2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "axs-application-server-deployment-9.6.90-346143" service. No singleton master will be elected. > Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1" > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4748 > URL: https://issues.jboss.org/browse/WFLY-4748 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: Tomas Hofman > Assignee: Paul Ferraro > Fix For: 10.0.0.Alpha6 > > > When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1". > This only happens after the second and other successive splits. After the first split both nodes execute the service correctly. > After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'. > I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted(): > {code} > public void viewAccepted(View view) { > // ... > for (Listener listener: this.listeners) { > listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView); > } > } > {code} > This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"

by Bui Van Nghiem (JIRA)

[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ] Bui Van Nghiem commented on WFLY-4748: -------------------------------------- I still face the same error on WildFly 9.0.2 after Full GC on master server: 2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "axs-application-server-deployment-9.6.90-346143" service. No singleton master will be elected. > Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1" > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4748 > URL: https://issues.jboss.org/browse/WFLY-4748 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: Tomas Hofman > Assignee: Paul Ferraro > Fix For: 10.0.0.Alpha6 > > > When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1". > This only happens after the second and other successive splits. After the first split both nodes execute the service correctly. > After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'. > I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted(): > {code} > public void viewAccepted(View view) { > // ... > for (Listener listener: this.listeners) { > listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView); > } > } > {code} > This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2279) Read resource operation handler does not preserve child order when registration has model overrides

by Paul Ferraro (JIRA)

Paul Ferraro created WFCORE-2279: ------------------------------------ Summary: Read resource operation handler does not preserve child order when registration has model overrides Key: WFCORE-2279 URL: https://issues.jboss.org/browse/WFCORE-2279 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha24 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Critical Normally, the read resource operation returns children of a given type in their correct order. However, if the child type has overrides (e.g. type=foo overrides type=*), the read resource operation returns the override children first, followed by the wildcard children in order. Order should be respected for all children of a given type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1777) Use separate resources for GET requests involving useStreamAsResponse

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1777?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1777: ------------------------------------- Fix Version/s: 3.0.0.Alpha25 2.2.1.Final (was: 3.0.0.CR1) > Use separate resources for GET requests involving useStreamAsResponse > --------------------------------------------------------------------- > > Key: WFCORE-1777 > URL: https://issues.jboss.org/browse/WFCORE-1777 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha25, 2.2.1.Final > > > A request for streamed content can potentially involve a large amount of content, e.g. a very large log file. We should limit the amount of resources (e.g. threads) available for handling such HTTP requests over the /management context, particularly in the case of GET requests where we don't do the cross-origin checks that we do with POST. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017