Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-1034

2 step domain operations do not resolve aliases properly

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 2.0.0.CR7
    • 2.0.0.CR6
    • Management
    • None

      For WFLY-5290, WFCORE-1022 was done to provide more context, however we still have some problems when doing:

      /profile=full-ha/subsystem=jgroups/stack=tcp/transport=TRANSPORT/thread-pool=default:write-attribute(name=keepalive-time,value=100)
      

      This is an alias which should resolve to

      /profile=full-ha/subsystem=jgroups/stack=tcp/transport=TCP/thread-pool=default:write-attribute(name=keepalive-time,value=100)
      

      The equivalent works fine in a standalone. Debugging using CLI commands, the initial read-operation-description ends up in PrepareStepHandler.executeDirectOperation()
      which does the right thing.

      However the write-attribute call ends up in

      	OperationCoordinatorStepHandler.execute() ->
      	OperationSlaveStepHandler.addSteps() ->
      	HostControllerExecutionSupport returns a domainOp ->
      	OperationSlaveStepHandler.addBasicStep()
      

      and OperationSlaveStepHandler.addBasicStep() resolves the OperationEntry differently from the standard/standalone prepare step handler, and from how PrepareStepHandler.executeDirectOperation() resolves it.

              kkhan1@redhat.com Kabir Khan
              kkhan1@redhat.com Kabir Khan
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: