[ https://issues.jboss.org/browse/WFCORE-622?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-622: ----------------------------------------- I think there are three cases relevant to this basic problem: 1) An end user invokes an op /host=oldslave/server=a/subsystem=foo:op. Here, perhaps the user understands that oldslave is using the old API, and therefore doesn't expect transformation. In that case, result transformation is invalid. But if they do expect transformation, there's no reason to assume that operation transformation is not expected as well. 2) The slave HC itself generates the op, as part of domain rollout. In this case, operation transformation is invalid, as the generated op is what the slave understands. But is result transformation valid? It may make the response consistent with current user expectations, or it may not, depending on the relationship to the operation transformation that may have gone along with the result transformation. I think this is not a real case though, as custom result transformers don't make much sense for the add/remove/write-attribute ops generated as part of a domain rollout. Those ops return 'undefined.' 3) A wildcard read (see WFCORE-282). So, /host=*/server=*/subsystem=foo:read-attribute(name=bar). The user would likely expect a consistent response for all servers. An example custom result transformer might be something that converts types, e.g. { "time" => 1, "unit" => "seconds"} becomes 1000L because the attribute type or response value type has changed from complex to a simple ms value. Another example is https://github.com/wildfly/wildfly/blob/8.x/jmx/src/main/java/org/jboss/a... which uses a result transformer to provide a value for a newly added attribute. -- This message was sent by Atlassian JIRA (v6.3.11#6341)