Adding ldap-realm in Elytron sometimes register capability even if add operation failed --------------------------------------------------------------------------------------- Key: WFCORE-1886 URL: https://issues.jboss.org/browse/WFCORE-1886 Project: WildFly Core Issue Type: Bug Components: Domain Management, Security Reporter: Ondrej Lukas Assignee: Brian Stansberry Priority: Critical In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail. I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model. Exception in server log: {code} ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("ldap-realm" => "ldap") ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'. at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158) at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449) at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441) at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274) at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) 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}