November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1997) NPE when non-existent attribute name is used for list-add operation

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1997?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-1997: ----------------------------------- AbstractCollectionHandler.execute() incorrectly assumes that it defines AttributeAccess during resource definition. I think it's there for later comparison with ModelType.LIST inside updateModel(). > NPE when non-existent attribute name is used for list-add operation > ------------------------------------------------------------------- > > Key: WFCORE-1997 > URL: https://issues.jboss.org/browse/WFCORE-1997 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha12 > Reporter: Chao Wang > Assignee: Chao Wang > > When I use non-existent attribute name for 'list-add' operation, I get following NPE in server.log: > {code} > 12:44:24,150 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("list-add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("https-listener" => "https") > ]): java.lang.NullPointerException > at org.jboss.as.controller.operations.global.AbstractCollectionHandler.execute(AbstractCollectionHandler.java:92) > at org.jboss.as.controller.operations.global.ListOperations$ListAddHandler.execute(ListOperations.java:108) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Yeah - I understand that it is my fault that I provided bad command. But still, server should not respond with NPE. Ideally it should told me that provided list attribute does not exist for particular element and should finish operation with error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1997) NPE when non-existent attribute name is used for list-add operation

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1997?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-7332 to WFCORE-1997: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1997 (was: JBEAP-7332) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: 3.0.0.Alpha12 (was: 7.1.0.DR8) > NPE when non-existent attribute name is used for list-add operation > ------------------------------------------------------------------- > > Key: WFCORE-1997 > URL: https://issues.jboss.org/browse/WFCORE-1997 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha12 > Reporter: Chao Wang > Assignee: Chao Wang > > When I use non-existent attribute name for 'list-add' operation, I get following NPE in server.log: > {code} > 12:44:24,150 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("list-add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("https-listener" => "https") > ]): java.lang.NullPointerException > at org.jboss.as.controller.operations.global.AbstractCollectionHandler.execute(AbstractCollectionHandler.java:92) > at org.jboss.as.controller.operations.global.ListOperations$ListAddHandler.execute(ListOperations.java:108) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Yeah - I understand that it is my fault that I provided bad command. But still, server should not respond with NPE. Ideally it should told me that provided list attribute does not exist for particular element and should finish operation with error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1996) AbstractRemoveStepHandler can endlessly loop if a child doesn't remove

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1996?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1996: ---------------------------------------- Assignee: Brian Stansberry > AbstractRemoveStepHandler can endlessly loop if a child doesn't remove > ---------------------------------------------------------------------- > > Key: WFCORE-1996 > URL: https://issues.jboss.org/browse/WFCORE-1996 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > See PR for WFLY-2640 for an example of a resource that doesn't get removed by a remove call. > In a situation like that, the AbstractRemoveStepHandler performRemove logic will never remove the resource, because it always finds it has the child. So it will just loop trying to remove the child and then calling itself again. > Possible solution is for AbstractRemoveStepHandler to have its own AttachmentKey<Set<PathAddress>> and before adding itself in a step, it adds its address to the set. Then if performRemove finds itself in the set it knows it's already tried to remove children and just removes itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1996) AbstractRemoveStepHandler can endlessly loop if a child doesn't remove

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1996?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1996: ---------------------------------------- Assignee: (was: Brian Stansberry) > AbstractRemoveStepHandler can endlessly loop if a child doesn't remove > ---------------------------------------------------------------------- > > Key: WFCORE-1996 > URL: https://issues.jboss.org/browse/WFCORE-1996 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > > See PR for WFLY-2640 for an example of a resource that doesn't get removed by a remove call. > In a situation like that, the AbstractRemoveStepHandler performRemove logic will never remove the resource, because it always finds it has the child. So it will just loop trying to remove the child and then calling itself again. > Possible solution is for AbstractRemoveStepHandler to have its own AttachmentKey<Set<PathAddress>> and before adding itself in a step, it adds its address to the set. Then if performRemove finds itself in the set it knows it's already tried to remove children and just removes itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1996) AbstractRemoveStepHandler can endlessly loop if a child doesn't remove

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1996: ---------------------------------------- Summary: AbstractRemoveStepHandler can endlessly loop if a child doesn't remove Key: WFCORE-1996 URL: https://issues.jboss.org/browse/WFCORE-1996 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry See PR for WFLY-2640 for an example of a resource that doesn't get removed by a remove call. In a situation like that, the AbstractRemoveStepHandler performRemove logic will never remove the resource, because it always finds it has the child. So it will just loop trying to remove the child and then calling itself again. Possible solution is for AbstractRemoveStepHandler to have its own AttachmentKey<Set<PathAddress>> and before adding itself in a step, it adds its address to the set. Then if performRemove finds itself in the set it knows it's already tried to remove children and just removes itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1995) Move aesh dependency to 0.66.13

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1995: ---------------------------------------- Summary: Move aesh dependency to 0.66.13 Key: WFCORE-1995 URL: https://issues.jboss.org/browse/WFCORE-1995 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Fix For: 3.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1995) Move aesh dependency to 0.66.13

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1995?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1995: ------------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/1928) > Move aesh dependency to 0.66.13 > ------------------------------- > > Key: WFCORE-1995 > URL: https://issues.jboss.org/browse/WFCORE-1995 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1995) Move aesh dependency to 0.66.13

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1995?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1995: ------------------------------------- Issue Type: Component Upgrade (was: Bug) > Move aesh dependency to 0.66.13 > ------------------------------- > > Key: WFCORE-1995 > URL: https://issues.jboss.org/browse/WFCORE-1995 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-751) Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-751?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev reassigned ELY-751: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron) > ------------------------------------------------------------------------------ > > Key: ELY-751 > URL: https://issues.jboss.org/browse/ELY-751 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Ilia Vassilev > Priority: Critical > Labels: static_analysis > > Coverity static-analysis scan found possible use of null object in {{LdapKeyStore}} constructor. > https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=57601... > The {{LdapKeyStore.Builder.build()}} method constructs the {{LdapKeyStore}} instance this way: > {code} > return new LdapKeyStore(spi, null, null); > {code} > and the constructor just calls parent ctor: > {code} > protected LdapKeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type) { > super(keyStoreSpi, provider, type); > } > {code} > And it fails with NPE if debug for {{KeyStore}} is enabled as the constructor contains: > {code} > if (!skipDebug && pdebug != null) { > pdebug.println("KeyStore." + type.toUpperCase() + " type from: " + > this.provider.getName()); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7607) Switch to the new WildFly Naming Client

by Farah Juma (JIRA)

Farah Juma created WFLY-7607: -------------------------------- Summary: Switch to the new WildFly Naming Client Key: WFLY-7607 URL: https://issues.jboss.org/browse/WFLY-7607 Project: WildFly Issue Type: Task Components: Naming Reporter: Farah Juma Assignee: Farah Juma Need to drop the old org.jboss.remote-naming module and turn it into an alias for the org.wildfly.naming-client module. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 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