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

ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 1.0.0.CR1
    • None
    • Management
    • None

      Getting WFCORE-282 to work surfaces a problem with :read-operation-description handling, which will get invoked in the background by the CLI whenever the user inputs a wildcard read op.

      Problem is ReadOperationDescriptionHandler.getDescribedOp, which attempts to deal with cases where there is no resource registration for the target address. It checks if the request is for a wildcard address, and if so it sees if there are concrete registrations for that address, and if so whether they all use the same description. If yes, it provides the description.

      This is broken in a couple ways:

      1) It assumes the wildcard applies to the last element in the address, which may not be the case with ops that support wildcard addressing schemes.

      2) It looks vulnerable to problems with proxy resources, particularly the /host=* case on the DC where there can be a normal ConcreteResourceRegistration for the local host=master child, and then ProxyControllerRegistration instances for the various host=slave-x registrations. I suspect this might lead to false results.

            bstansbe@redhat.com Brian Stansberry
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: