[jboss-jira] [JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-621:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1028, https://github.com/wildfly/wildfly/pull/8052  (was: https://github.com/wildfly/wildfly-core/pull/1022, https://github.com/wildfly/wildfly/pull/8052)


> Support legacy slaves when invoking wildcard reads in a domain
> --------------------------------------------------------------
>
>                 Key: WFCORE-621
>                 URL: https://issues.jboss.org/browse/WFCORE-621
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.Beta6
>
>
> This is a follow-on to WFCORE-282.
> The WFCORE-282 solution will not work for requests with address patterns {code}/host=*/server=*{code} or {code}/host=somename/server=*{code} if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
> In particular, it won't work with slaves running EAP 6.x.
> The problem is with either of those address patterns the DC will send a request addressed to {code}/host=somename/server=*{code} to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
> Potentially this could be fixed by having the DC detect these patterns and not call {code}/host=somename/server=*{code}, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)