[jboss-jira] [JBoss JIRA] (WFCORE-323) Validate composite operation steps just before executing them

[Radoslav Husar (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384031#comment-13384031 ] 

Radoslav Husar commented on WFCORE-323:
---------------------------------------

Also note that extension :remove within a batch does not work:

{noformat}
[standalone at localhost:10090 /] batch
[standalone at localhost:10090 / #] /subsystem=mail:remove
[standalone at localhost:10090 / #] /extension=org.jboss.as.mail:remove
[standalone at localhost:10090 / #] run-batch
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
Step: step-1
Operation: /subsystem=mail:remove
Failure: WFLYCTL0158: Operation handler failed: java.lang.NullPointerException
{noformat}

server log

{noformat}
18:05:27,501 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("remove") failed - address: ([
    ("subsystem" => "mail"),
    ("mail-session" => "default")
]): java.lang.NullPointerException
	at org.jboss.as.controller.CapabilityRegistry.getCapabilitiesForAddress(CapabilityRegistry.java:422)
	at org.jboss.as.controller.CapabilityRegistry.capabilityReloadRequired(CapabilityRegistry.java:399)
	at org.jboss.as.controller.AbstractOperationContext.reloadRequired(AbstractOperationContext.java:1121)
	at org.jboss.as.controller.ServiceRemoveStepHandler.performRuntime(ServiceRemoveStepHandler.java:124)
	at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:82)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421)
	at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
	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.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
	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)
{noformat}

> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
>                 Key: WFCORE-323
>                 URL: https://issues.jboss.org/browse/WFCORE-323
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>              Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")] 
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)