[jboss-jira] [JBoss JIRA] (WFCORE-642) ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFCORE-642:
-----------------------------------------

Example of an issue caused by this:

https://gist.github.com/heiko-braun/62097308030d0d4ff423

> ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely
> --------------------------------------------------------------------------------------
>
>                 Key: WFCORE-642
>                 URL: https://issues.jboss.org/browse/WFCORE-642
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 1.0.0.CR1
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)