[jboss-jira] [JBoss JIRA] (WFLY-2924) management-native socket binding is missing, CLI must use management-http port
[
https://issues.jboss.org/browse/WFLY-2924?page=com.atlassian.jira.plugin....
]
Michal Babacek updated WFLY-2924:
---------------------------------
Description:
With WildFly 8.0.0.CR1, it was possible to use jboss-cli on {{management-native}} socket
binding, provided that one used {{remoting://}} as a prefix to the address, e.g.:
{noformat}
./jboss-cli.sh --connect --controller=remoting://10.16.88.19:10091 --command=:shutdown
{noformat}
With the current {{wildfly-8.0.1.Final-SNAPSHOT}}, HEAD:be3a13e6,
the whole {{<socket-binding name="management-native"
interface="management...}} is missing from socket binding groups and one has to use
{{management-http}} with jboss-cli, this time *without* {{remoting://}} in the
address:port.
Since I had failed to find any Jira requesting this feature and because it breaks
automation, I considered this to be a bug rather than a feature.
If one needs to have a stable automation that operates several standalone instances on a
one box, relying on port-offset and management socket bindings for jboss-cli, what should
one use so as not to be forced to patch it with every WildFly release? Which socket
binding? With or without {{remoting://}}? THX :-)
was:
With WildFly 8.0.0.CR1, it was possible to use jboss-cli on {{management-native}} socket
binding, provided that one used {{remoting://}} as a prefix to the address, e.g.:
{noformat}
./jboss-cli.sh --connect --controller=remoting://10.16.88.19:10091 --command=:shutdown
{noformat}
With the current {{wildfly-8.0.1.Final-SNAPSHOT}}, HEAD:be3a13e6,
the whole {{<socket-binding name="management-native"
interface="management...}} is missing from socket binding groups and one has to use
{{management-http}} with jboss-cli, this time *without* {{remoting://}} in the
address:port.
Since I had failed to find any Jira requesting this feature and because it breaks
automation, I considered this to be a bug rather than a feature.
If one needs to have a stable automation that operates several standalone instances on a
one box, relying on port-offset and management socket bindings for jboss-cli, what should
one use so as not to be forced to patch it with every WildFly release? Which socket
binding? Wit or without {{remoting://}}? THX :-)
management-native socket binding is missing, CLI must use
management-http port
------------------------------------------------------------------------------
Key: WFLY-2924
URL: https://issues.jboss.org/browse/WFLY-2924
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Domain Management
Affects Versions: 8.0.1.Final
Environment: Irrelevant
Reporter: Michal Babacek
Assignee: Darran Lofthouse
Labels: management
With WildFly 8.0.0.CR1, it was possible to use jboss-cli on {{management-native}} socket
binding, provided that one used {{remoting://}} as a prefix to the address, e.g.:
{noformat}
./jboss-cli.sh --connect --controller=remoting://10.16.88.19:10091 --command=:shutdown
{noformat}
With the current {{wildfly-8.0.1.Final-SNAPSHOT}}, HEAD:be3a13e6,
the whole {{<socket-binding name="management-native"
interface="management...}} is missing from socket binding groups and one has to use
{{management-http}} with jboss-cli, this time *without* {{remoting://}} in the
address:port.
Since I had failed to find any Jira requesting this feature and because it breaks
automation, I considered this to be a bug rather than a feature.
If one needs to have a stable automation that operates several standalone instances on a
one box, relying on port-offset and management socket bindings for jboss-cli, what should
one use so as not to be forced to patch it with every WildFly release? Which socket
binding? With or without {{remoting://}}? THX :-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira