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

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046465#comment-13046465 ] 

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.  

>  We also have Debug As > Remote Java Application which I believe uses the exact same API but allow for launching a remote java app. 

This debug as -> remote java application is, obviously, contributed by platform

> It would be nice if we could [...]  have remote java application just use the existing model so we don't have this use of sun api's spread out over two places.

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".  

> which I believe uses the exact same API but allow for launching a remote java app.

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. 

> unify/merge "Debug As... > Remote Java Application" with JMX vm list
> --------------------------------------------------------------------
>
>                 Key: JBIDE-19397
>                 URL: https://issues.jboss.org/browse/JBIDE-19397
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: common/jst/core, server
>            Reporter: Max Rydahl Andersen
>            Assignee: Rob Stryker
>
> today we got jmx view that lists running hotspot jvms and allow introspection.
> We also have Debug As > Remote Java Application which I believe uses the exact same API but allow for launching a remote java app.
> It would be nice if we could make jmx view have a context menu for "connect debugger" that works in similar fashion  and even better, have remote java application just use the existing model so we don't have this use of sun api's spread out over two places.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)