[jbosstools-issues] [JBoss JIRA] (JBIDE-19397) unify/merge "Debug As... > Remote Java Application" with JMX vm list

[ https://issues.jboss.org/browse/JBIDE-19397?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19397: ------------------------------------- I find it very difficult to understand this suggestion. The Debug as -> Remote Java Application, only connects a debugger to servers that were launched with debug flags, specifically -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044. If a user has not exposed a debugging port, then the remote java application (or any other implementation, even one I write myself) cannot connect to it to debug. Looking at JavaRemoteApplicationLaunchConfigurationDelegate, I see absolutely no jdk classes or references that overlap in any way with any code in jvmmonitor. A significant amount of the implementation appears to be in org.eclipse.wst.jsdt.debug package, with classes like CFTransportService, packet handshake readings, all sorts of very low level protocol writing. This debug as -> remote java application is, obviously, contributed by platform I have absolutely no idea what you're asking. We do not control the functionality of "Remote Java Application". We also have no existing model that does absolutely anything with the packet protocol used to connect a debugger, so even if we did control the "Remote Java Application" launch config, we cannot "have remote java application just use the existing model". I have no idea where you get this belief from. JVM Monitor's discovering existing jvm's is run through a sun class, yes. But Remote Java Application launch configurations requires a host and a port, does not use any such sun APIs, and seems to be a protocol, fully implemented by eclipse in the org.eclipse.wst.jsdt.debug packages with no use of internal sun jdk classes at all. I did see a few references to strings like "com.sun.jdi.SocketListen", but these seem to be a name of a ListeningConnector found via the Bootstrap.virtualMachineManager().listeningConnectors().iterator(); API, which JDT seems to compile against and not get via reflection or anything. -- This message was sent by Atlassian JIRA (v6.3.11#6341)