December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7771) Failed to obtain ApplicationPolicy for domain other

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7771?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved UNDERTOW-875 to WFLY-7771: ----------------------------------------------- Project: WildFly (was: Undertow) Key: WFLY-7771 (was: UNDERTOW-875) > Failed to obtain ApplicationPolicy for domain other > --------------------------------------------------- > > Key: WFLY-7771 > URL: https://issues.jboss.org/browse/WFLY-7771 > Project: WildFly > Issue Type: Bug > Environment: Centos 7/Wildfly 10.1.0.Final > Reporter: Albert Borgen > Assignee: Stuart Douglas > Priority: Critical > > 2016-10-16 21:39:04,743 ERROR [io.undertow.websockets.jsr.request] (default task-242) UT026006: Exception running web socket method: java.lang.RuntimeException: java.lang.IllegalStateException: PBOX00048: Failed to obtain ApplicationPolicy for domain other > at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:577) > at io.undertow.websockets.jsr.ServerWebSocketContainer$6.run(ServerWebSocketContainer.java:561) > at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException: PBOX00048: Failed to obtain ApplicationPolicy for domain other > at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:42) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:575) > ... 5 more -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2099) Make OperationTimeoutTestCase more robust by increasing timeout for setup/teardown ops

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2099: ---------------------------------------- Summary: Make OperationTimeoutTestCase more robust by increasing timeout for setup/teardown ops Key: WFCORE-2099 URL: https://issues.jboss.org/browse/WFCORE-2099 Project: WildFly Core Issue Type: Task Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry OperationTimeoutTestCase deliberately runs with very low blocking timeouts, in order to execute reasonably efficiently, not waiting long periods for timeouts. But those timeouts are also in effect for various setup/teardown ops, and that can lead to spurious failures like this: {code} org.jboss.as.test.integration.management.util.MgmtOperationException: Management operation failed. at org.jboss.as.test.integration.domain.management.util.DomainTestUtils.executeForResult(DomainTestUtils.java:160) at org.jboss.as.test.integration.domain.OperationTimeoutTestCase.executeForResult(OperationTimeoutTestCase.java:306) at org.jboss.as.test.integration.domain.OperationTimeoutTestCase.tearDownDomain(OperationTimeoutTestCase.java:192) ------- Stdout: ------- [Host Controller] &amp#27;[31m&amp#27;[0m&amp#27;[0m13:42:23,027 INFO [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 5) WFLYCTL0409: Execution of operation 'remove' on remote process at address '[&amp#27;[0m [Host Controller] ("host" => "slave"), [Host Controller] ("server" => "other-two") [Host Controller] ]' timed out after 2000 ms while awaiting initial response; remote process has been notified to terminate operation [Server:other-two] 13:42:23,033 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (ServerService Thread Pool -- 12) Registered blocker-test operations [Server:main-three] 13:42:23,034 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (ServerService Thread Pool -- 4) Registered blocker-test operations [Server:main-one] 13:42:23,034 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (ServerService Thread Pool -- 7) Registered blocker-test operations [Server:other-two] 13:42:23,034 INFO [org.jboss.as.protocol] (ServerService Thread Pool -- 2) WFLYPRT0057: cancelled task by interrupting thread Thread[ServerService Thread Pool -- 12,5,ServerService ThreadGroup] [Host Controller] &amp#27;[0m&amp#27;[0m13:42:23,042 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 9) Registered blocker-test operations&amp#27;[0m [Host Controller] &amp#27;[0m&amp#27;[0m13:42:23,045 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (management-handler-thread - 2) Registered blocker-test operations&amp#27;[0m Failed operation: { "operation" => "remove", "address" => [("extension" => "org.wildfly.extension.blocker-test")] } Response: { "outcome" => "failed", "result" => undefined, "failure-description" => "WFLYDC0022: Operation failed or was rolled back on all servers.", "rolled-back" => true, "server-groups" => { "main-server-group" => {"host" => { "master" => {"main-one" => {"response" => { "outcome" => "failed", "rolled-back" => true }}}, "slave" => {"main-three" => {"response" => { "outcome" => "failed", "result" => undefined, "rolled-back" => true }}} }}, "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => { "outcome" => "failed", "result" => undefined, "failure-description" => "WFLYCTL0409: Execution of operation 'remove' on remote process at address '[ (\"host\" => \"slave\"), (\"server\" => \"other-two\") ]' timed out after 2000 ms while awaiting initial response; remote process has been notified to terminate operation", "rolled-back" => true }}}}} } } {code} Simple solution is to add the blocking-timeout header to those ops and use a longer timeout (say 20 secs). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7770) WildFly artifacts have unnecessary transitive runtime dependency on org.wildfly.checkstyle:wildfly-checkstyle-config

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7770: ---------------------------------- Summary: WildFly artifacts have unnecessary transitive runtime dependency on org.wildfly.checkstyle:wildfly-checkstyle-config Key: WFLY-7770 URL: https://issues.jboss.org/browse/WFLY-7770 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 This is only needed for compile phase, and should use provided scope. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7769) WildFly artifacts have unnecessary transitive runtime dependency on org.wildfly.checkstyle:wildfly-checkstyle-config

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7769: ---------------------------------- Summary: WildFly artifacts have unnecessary transitive runtime dependency on org.wildfly.checkstyle:wildfly-checkstyle-config Key: WFLY-7769 URL: https://issues.jboss.org/browse/WFLY-7769 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 This is only needed for compile phase, and should use provided scope. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-827) Anonymous principal is not mapable to an identity

by David Lloyd (JIRA)

David Lloyd created ELY-827: ------------------------------- Summary: Anonymous principal is not mapable to an identity Key: ELY-827 URL: https://issues.jboss.org/browse/ELY-827 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-826) Permission check for SecurityDomain.mapPrincipal and mapName

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-826?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated ELY-826: ---------------------------- Description: Plus, access to privileged mapping functions for above. > Permission check for SecurityDomain.mapPrincipal and mapName > ------------------------------------------------------------ > > Key: ELY-826 > URL: https://issues.jboss.org/browse/ELY-826 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > > Plus, access to privileged mapping functions for above. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-826) Permission check for SecurityDomain.mapPrincipal and mapName

by David Lloyd (JIRA)

David Lloyd created ELY-826: ------------------------------- Summary: Permission check for SecurityDomain.mapPrincipal and mapName Key: ELY-826 URL: https://issues.jboss.org/browse/ELY-826 Project: WildFly Elytron Issue Type: Feature Request Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-825) Additional Principal types

by David Lloyd (JIRA)

David Lloyd created ELY-825: ------------------------------- Summary: Additional Principal types Key: ELY-825 URL: https://issues.jboss.org/browse/ELY-825 Project: WildFly Elytron Issue Type: Feature Request Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd Add some additional principal types, which can be used with realms to locate specific identities for the purpose of self-service. Make realm implementations return useful principal values in their getPrincipal() methods which can be used for this purpose. Make the authentication context code recognize special principals that can be used to load an identity directly from a target realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7768) Singleton deployment marked with jboss-all.xml will fail if deployed with a non HA profile

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7768: -------------------------------------- Summary: Singleton deployment marked with jboss-all.xml will fail if deployed with a non HA profile Key: WFLY-7768 URL: https://issues.jboss.org/browse/WFLY-7768 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Wolf-Dieter Fink Assignee: Paul Ferraro Priority: Minor If an application which is marked as a cluster HA-Singleton deployment is added to a server without a HA configuration, exactly without having the singleton subsystem, the parser for the application will fail as it does not use the related xsd. For conveniance and user experiance this should be possible -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2096) ServiceTarget and ServiceBuilder provided by OperationContext remain coupled to the context after the op is complete

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2096?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2096: ------------------------------------- Description: OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService. If this is done though, the target and builders continue to hold a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objects when the operation is complete. was: OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. (As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService. If this is done though, the target and builders continue to a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objecdts when the operation is complete. > ServiceTarget and ServiceBuilder provided by OperationContext remain coupled to the context after the op is complete > -------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2096 > URL: https://issues.jboss.org/browse/WFCORE-2096 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha15 > > > OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService. > If this is done though, the target and builders continue to hold a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objects when the operation is complete. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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