[jboss-jira] [JBoss JIRA] (WFLY-861) modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly.

modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly. ------------------------------------------------------------------------------------------------------------------- Key: WFLY-861 URL: https://issues.jboss.org/browse/WFLY-861 Project: WildFly Issue Type: Bug Security Level: Public(Everyone can see) Components: CLI Environment: EAP6 Reporter: Simeon Pinder Assignee: Radoslav Husar Priority: Critical Labels: rhq Fix For: 8.0.0.Final The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level). Without this information it is ambiguous how and which contexts will be affected when you execute the following operations: disable, disable-context, enable, enable-context, stop, stop-context. The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute. There is currently no consistent way to determine what a valid cluster identifier should be. The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem. This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated. As the identifier is used by modcluster the identifier should be exposed consistently. Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though.