[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2806: ------------------------------------------ Possibilities: 1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch. 2) A simpler variant of that would be <option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/> That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx} properties and the different ways they can be configured. But the user has to understand this special property. 3) Another variant is to use special expression syntax instead of a special property: <option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/> But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc. The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. So something like this would not work normally: /host=master:read-resource(recursive=true,resolve-expressions=true) Even something more targeted would not work: /host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true) This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible. -- This message was sent by Atlassian JIRA (v7.2.3#72005)