November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2058) Add a DomainXml_5 Parser

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2058?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2058: ------------------------------- Fix Version/s: 3.0.0.Alpha14 (was: 3.0.0.Alpha13) > Add a DomainXml_5 Parser > ------------------------ > > Key: WFCORE-2058 > URL: https://issues.jboss.org/browse/WFCORE-2058 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2059) Deprecate management role mappings

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2059?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2059: ------------------------------- Fix Version/s: 3.0.0.Alpha14 (was: 3.0.0.Alpha13) > Deprecate management role mappings > ---------------------------------- > > Key: WFCORE-2059 > URL: https://issues.jboss.org/browse/WFCORE-2059 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha14 > > > The Elytron SecurityDomain becomes the common point where policy information such as role mapping should be handled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2060) Support Elytron RoleMapper categories

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2060?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2060: ------------------------------- Fix Version/s: 3.0.0.Alpha14 (was: 3.0.0.Alpha13) > Support Elytron RoleMapper categories > ------------------------------------- > > Key: WFCORE-2060 > URL: https://issues.jboss.org/browse/WFCORE-2060 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha14 > > > (Support for this could be added later, just scheduling in current releases for now if we have time) > The Elytron role mapping configuration can contain different mappers for different categories, this issue is to make use of categories for management role mapping. > We need to decide if we use hard coded names, some naming convention which is part hard coded, part based on deployment or a fully configurable category. > On the access=authorization resource this could simply be an optional String 'role-category' if we go for configured. Possibly a boolean to state if we fallback to the default RoleMapping on the domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1852) Logging configuration service for dynamic deployment resources uses wrong service name for deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1852?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1852: ------------------------------------- Component/s: Logging > Logging configuration service for dynamic deployment resources uses wrong service name for deployments > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1852 > URL: https://issues.jboss.org/browse/WFCORE-1852 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > > Ideally if the use of a service can be removed that would be best. What's needed is a way to associate a deployments resource with a {{LogContextConfiguration}}. One option is to use a custom resource that the OSH can get the {{LogContextConfiguration}} from. This is already done for the child resources. See the {{LoggingDeploymentResources}}. The OSH can cast the resource and just get the configuration. > {quote} > [12:08 PM] Brian Stansberry: @jperkins this doesn't look right: https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java.... > [12:09 PM] Brian Stansberry: AFAICT it is using the management name of a deployment to create an MSC ServiceName > [12:10 PM] James R Perkins: @BrianStansberry Hmm. ...yeah. Let me look at why I was doing that. > [12:13 PM] James R Perkins: @BrianStansberry Yes that's what it's doing which thinking about it does seem wrong. Essentially it's trying to figure out which service to use for a dynamic resource on the /deployment=some.war/subsystem=logging/configuration=whatever > [12:14 PM] Brian Stansberry: you need to use the runtime-name attribute of the deployment > [12:14 PM] James R Perkins: Really it's kind of a bad use case for a service. > [12:14 PM] Brian Stansberry: I guess subdeployment has one too, although it's redundant > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7701) All subsystems referencing a SecurityDomain should optionally support a role mapping category

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7701?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7701: ----------------------------------- Priority: Minor (was: Major) > All subsystems referencing a SecurityDomain should optionally support a role mapping category > --------------------------------------------------------------------------------------------- > > Key: WFLY-7701 > URL: https://issues.jboss.org/browse/WFLY-7701 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > The role mapping category allows for a common security domain to be used with different role mapping definitions. Also a configuration option should be provided to decide if it should drop to default. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7701) All subsystems referencing a SecurityDomain should optionally support a role mapping category

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7701: -------------------------------------- Summary: All subsystems referencing a SecurityDomain should optionally support a role mapping category Key: WFLY-7701 URL: https://issues.jboss.org/browse/WFLY-7701 Project: WildFly Issue Type: Feature Request Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 The role mapping category allows for a common security domain to be used with different role mapping definitions. Also a configuration option should be provided to decide if it should drop to default. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2060) Support Elytron RoleMapper categories

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2060?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2060: ------------------------------------- Component/s: Security > Support Elytron RoleMapper categories > ------------------------------------- > > Key: WFCORE-2060 > URL: https://issues.jboss.org/browse/WFCORE-2060 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha13 > > > (Support for this could be added later, just scheduling in current releases for now if we have time) > The Elytron role mapping configuration can contain different mappers for different categories, this issue is to make use of categories for management role mapping. > We need to decide if we use hard coded names, some naming convention which is part hard coded, part based on deployment or a fully configurable category. > On the access=authorization resource this could simply be an optional String 'role-category' if we go for configured. Possibly a boolean to state if we fallback to the default RoleMapping on the domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2060) Support Elytron RoleMapper categories

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2060: ---------------------------------------- Summary: Support Elytron RoleMapper categories Key: WFCORE-2060 URL: https://issues.jboss.org/browse/WFCORE-2060 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha13 (Support for this could be added later, just scheduling in current releases for now if we have time) The Elytron role mapping configuration can contain different mappers for different categories, this issue is to make use of categories for management role mapping. We need to decide if we use hard coded names, some naming convention which is part hard coded, part based on deployment or a fully configurable category. On the access=authorization resource this could simply be an optional String 'role-category' if we go for configured. Possibly a boolean to state if we fallback to the default RoleMapping on the domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2059) Deprecate management role mappings

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2059: ---------------------------------------- Summary: Deprecate management role mappings Key: WFCORE-2059 URL: https://issues.jboss.org/browse/WFCORE-2059 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha13 The Elytron SecurityDomain becomes the common point where policy information such as role mapping should be handled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2137) JGroups: one slow/stuck node slows/freezes entire cluster

by Bharad S (JIRA)

[ https://issues.jboss.org/browse/JGRP-2137?page=com.atlassian.jira.plugin.... ] Bharad S commented on JGRP-2137: -------------------------------- Quick question - we checked versions 3.6.5 and 3.6.11 -- seems like 'NioServer' in these versions doesn't have an option to set a custom socket factory (for enabling SSL using our custom implementation of key store, trust store, etc). Looks like this is possible 4.0.0.Beta1 onwards.. For using a custom socket factory with NioServer would you recommend using one of the 4.0.0.Beta releases or should we use 3.6.5 and try to backport the NioServer and related changes from one of the 4.0.0.Beta versions? Thanks. > JGroups: one slow/stuck node slows/freezes entire cluster > --------------------------------------------------------- > > Key: JGRP-2137 > URL: https://issues.jboss.org/browse/JGRP-2137 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: Multi node cluster. Uses TUNNEL mode with GossipRouter, TCP. > Reporter: Bharad S > Assignee: Bela Ban > Attachments: replication-server.xml > > > We have a multi node cluster with one node (say Node A) running the gossip router. We use TUNNEL mode, i.e., other nodes in cluster can talk to each other only via Node A. If one of the nodes in the cluster (say Node B) is slow in reading or gets stuck while reading from the channel, it affects the entire cluster. Inter node gossip also gets stuck and the nodes fall out of cluster. > Thread dump on Node A indicate that 'ConnectionHandler' for node B stuck (at SocketOutputStream.socketWrite) while it is holding on to a lock, thus blocking ConnectionHandlers for all other nodes. > --snip (from thread dump on Node A) -- > "gossip-handlers-129" #1088 daemon prio=5 os_prio=0 tid=0x00007f65d20ce800 nid=0x2353 runnable [0x00007f6557efd000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > at java.net.SocketOutputStream.write(SocketOutputStream.java:153) > at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431) > at sun.security.ssl.OutputRecord.write(OutputRecord.java:417) > at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:857) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:828) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) > - locked <0x00000005f2445028> (a sun.security.ssl.AppOutputStream) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > - locked <0x00000005f248a210> (a java.io.BufferedOutputStream) > at java.io.DataOutputStream.flush(DataOutputStream.java:123) > at org.jgroups.stack.GossipRouter.sendToMember(GossipRouter.java:607) > - locked <0x00000005f248a1f0> (a java.io.DataOutputStream) > at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:590) > - locked <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap) > at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487) > at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63) > at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753) > at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706) > at java.lang.Thread.run(Thread.java:745) > --snip end-- > Other gossip-handler threads (meant for other nodes in the cluster) on Node A wait for acquiring lock on the ConnectionHandler map at following place: GossipRouter.java, method: sendToAllMembersInGroup > --snip-- > "gossip-handlers-128" > #1078 daemon prio=5 os_prio=0 tid=0x00007f65d20ce000 nid=0x2343 waiting > for monitor entry [0x00007f654c258000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583) > - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap) > at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487) > at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63) > at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753) > at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706) > at java.lang.Thread.run(Thread.java:745) > "gossip-handlers-127" > #1073 daemon prio=5 os_prio=0 tid=0x00007f65d01a6800 nid=0x233c waiting > for monitor entry [0x00007f6697afb000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583) > - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap) > at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487) > at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63) > at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753) > at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706) > at java.lang.Thread.run(Thread.java:745) > --snip end-- > If node B were to go down, JGroups quickly takes it out of the cluster and > there is no problem. But if it stays in the cluster and is slow/stuck, is > there a way to avoid rest of the cluster getting affected? We'd > appreciate any help/pointers. Thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 November 2016