[ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-621: ------------------------------------ Description: 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. was: This is a follow-on to WFCORE-282. The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* 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 /host=somename/server=* 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 /host=somename/server=*, 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.3.15#6346)