May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8861) Create test case for Elytron Aggregate Principal Transformer

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-8861: ---------------------------------- Summary: Create test case for Elytron Aggregate Principal Transformer Key: WFLY-8861 URL: https://issues.jboss.org/browse/WFLY-8861 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ondrej Lukas Create test case for Elytron Aggregate Principal Transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1192?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1192: ------------------------------ Description: In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain. [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... was: In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... > HTTP status 500 when no principal is returned by aggregate-principal-transformer > -------------------------------------------------------------------------------- > > Key: ELY-1192 > URL: https://issues.jboss.org/browse/ELY-1192 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. > This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). > This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain. > [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2741) ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2741?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2741: ------------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1455588|https://bugzilla.redhat.com/show_bug.cgi?id=1455588] from POST to MODIFIED > ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers > --------------------------------------------------------------------------------------- > > Key: WFCORE-2741 > URL: https://issues.jboss.org/browse/WFCORE-2741 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Critical > Fix For: 3.0.0.Beta22 > > > In a managed domain if you configure a vault with the 'module' attribute set, when the HC launches a server that attribute value is not passed to the server in the relevant operation in the boot operation list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2890) OperationContextImpl leaks to OperationContextImpl.OperationContextServiceRegistry

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2890: ---------------------------------------- Summary: OperationContextImpl leaks to OperationContextImpl.OperationContextServiceRegistry Key: WFCORE-2890 URL: https://issues.jboss.org/browse/WFCORE-2890 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry WorkerResourceDefinition.WorkerResource is holding a ref to the OperationContextImpl.OperationContextServiceRegistry. That's not a static class so that leaks the original OperationContextImpl. Fix is to make it static and when the op is done disconnect the OC the way we do with OperationContextImpl.ContextServiceTarget. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5627: ------------------------------------ Until https://issues.jboss.org/browse/WFLY-5685 is complete, you can only see these metrics via JMX. > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by PEANO LUCA (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] PEANO LUCA commented on WFLY-5627: ---------------------------------- sorry but how i can get replicated web cache metrics via jboss cli? > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1550) wildfly-init-redhat.sh script does not work on RHEL 5 OS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1550?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1550: ------------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1328146|https://bugzilla.redhat.com/show_bug.cgi?id=1328146] from POST to MODIFIED > wildfly-init-redhat.sh script does not work on RHEL 5 OS > -------------------------------------------------------- > > Key: WFCORE-1550 > URL: https://issues.jboss.org/browse/WFCORE-1550 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.CR2 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > Fix For: 3.0.0.Alpha2 > > > Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: > grep -o '[0-9]*' $JBOSS_MARKERFILE > This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5627: ------------------------------------ [~lpeano] The routing information is stored in a cache instance per server (i.e. undertow "server"), named using the name of that server (e.g. <server name="default-server">...</server>. I'm not sure why statistics from this cache would be of any interest. > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1198) AuthenticationConfiguration ACC changes

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1198?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1198: ---------------------------------- Like ELY-1212, this issue relates to locking in dynamic behavior on an AuthenticationConfiguration so that subsequent usages are stable. > AuthenticationConfiguration ACC changes > --------------------------------------- > > Key: ELY-1198 > URL: https://issues.jboss.org/browse/ELY-1198 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > > The ACC should be captured dynamically if not given, and established to the auth config. The ACC should not figure into equals/hashCode decisions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1212) The forward identity should be captured in AuthenticationContextConfigurationClient.getAuthenticationConfiguration()

by David Lloyd (JIRA)

David Lloyd created ELY-1212: -------------------------------- Summary: The forward identity should be captured in AuthenticationContextConfigurationClient.getAuthenticationConfiguration() Key: ELY-1212 URL: https://issues.jboss.org/browse/ELY-1212 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd Fix For: 2.0.0.Alpha1 When there is a forwarded identity (from a configured security domain for example), the principal and credential set should be captured when the AuthenticationConfiguration is captured by the client. This will allow the identity to flow across threads without mixing up connection sharing considerations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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