[
https://issues.jboss.org/browse/WFLY-1146?page=com.atlassian.jira.plugin....
]
James Livingston commented on WFLY-1146:
----------------------------------------
If we don't want this that's fine.
Although it does use internal Sun API which is obviously not portable or stable, if
it's run on a JVM which does not support it, it will simply log the CFNE/MNFE at debug
level and continue as it currently behaves. Supporting compiling without such a VM could
trivially be done by using reflection.
I don't see how this would break non-local authentication. If the user manually enters
the service URL then the data in the instrumentation buffer is not used, so it
shouldn't make a difference. If the user picks the process from the list, then
JConsole can't (at least in my experience) connect at all because it doesn't know
to use the remoting service URL rather than the Sun JDK standard RMI one.
Export remoting-JMX address via JVM instrumentation buffer
----------------------------------------------------------
Key: WFLY-1146
URL:
https://issues.jboss.org/browse/WFLY-1146
Project: WildFly
Issue Type: Feature Request
Components: JMX
Reporter: James Livingston
Assignee: Darran Lofthouse
Fix For: 8.0.0.Alpha3
Currently to connect to the AS with JConsole you need to manually enter the
service:jmx:remoting-jmx:// address. When the local process connection is used, it
retrieves the connection address via the Sun JDK management instrumentation buffer.
The exported address can be set via sun.management.ConnectorAddressLink.export(), and
doing that would allow JConsole to connect without typing in the address (although still
obviously require the jars to be on the classpath).
--
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