[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-1752 at 1/13/17 10:54 AM: -------------------------------------------------------------------- And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation. I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can do in a reasonable manner. was (Author: brian.stansberry): And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation. I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can't do in a reasonable manner. -- This message was sent by Atlassian JIRA (v7.2.3#72005)