Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JSDT/Debug/Rhino/Rhino Debug Wire Protocol

< JSDT‎ | Debug‎ | Rhino
JSDT Debug
Website
Download
Community
Mailing List • Forums • IRC • mattermost
Issues
Open • Help Wanted • Bug Day
Contribute
Browse Source • Project Set File

Overview

The Rhino Debug Wire Protocol (RDWP) is an adapted version of the v8 protocol using JSON to communicate with the remote Rhino interpreter executing in debug mode.

The RDWP was chosen to be JSON-based for a few reasons:

  1. It can be more easily extended to add new events, requests or responses.
  2. It is easier to understand by consumers
  3. It follows the de-facto JSON standard, which could allow it to communicate with other JSON-based efforts. Note that name:value paris in a JSON packet are not necessarily ordered but that values within an array value are ordered.

Packets

The RDWP performs all communication with the remote interpreter using packets over a socket. The payload of each packet is the JSON string describing the event, request or response with a preamble containing the content length and a line terminator.

All packets follow the general form shown below. Every packet contains a unique sequence number based on its origin - client or remote interpreter. Sequence numbers begin at zero and increment by one for each packet sent. Request sequence numbers will overlap with event and response sequence numbers generated by the remote interpreter. However, each response packet contains the sequence number of its associated request packet in the request_seq argument such that responses can be matched up with requests. 

<content_length>
\r\n\
{
  "type":<packet_type>,
  "seq":<packet_sequence>,
  "body":{}
}

Event

Event packets are sent to the client only when the client has created an event request for a given event. Event packets are not sent if the client has not requested them.

All event packets have the general form: 

<content_length>
\r\n
{
  "type":"event",
  "seq":<packet_sequence>,
  "event":<event_type>,
  "body":{}
}

The complete list of events that can be used in <event_type> are available in the Events section below

Request

A request packet is used to ask the remote interpreter to perform some operation. The compete listing of requests that can be made is available in the Requests section below.

All request packets have the general form: 

<content_length>
\r\n
{
  "type":"request",
  "command":<command>, 
  "seq":<packet_sequence>,
  "arguments":{<argument_list>}
}

A complete listing of requests that can be used in <command> are available in the Requests section below.

Response

A response packet is sent by the remote interpreter corresponding directly to each request packet that has been sent from the cleint. Response packets are never sent if a request has not been made.

All response packets are of the form: 

<content_length>
\r\n
{
  "type":"response",
  "command":<command>,
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{}
}

A complete listing of responses that can be used in <command> are available in the Responses section below.

Events

break

A break event is sent when execution of the remote program has suspended - from a previous step operation, a breakpoint, or when a debugger; statement has been encountered.

The event will be sent only if the client has registered a request for the specific event type.

The following describes what registered clients will be notified:

event from a breakpoint 
client will be notified if a BreakpointRequest has been registered
event from a debugger; statement 
client will be notified if a DebuggerStatementRequest has been registered
event from a step operation 
client will be notified if a StepRequest has been registered
event from a step operation where the step type is suspend 
client will be notified if a SuspendRequest has been registered

The general form of the break event is: 

<content_length>
\r\n
{
  "type":"event",
  "seq":<packet_sequence>,
  "event":"break",
  "body":{
          "contextId":<context_id>,
          "debuggerStatement":<is_debugger>,
          "threadId":<thread_id>,
          "step":<step_kind>,
          "line":<line_number>,
          "scriptId":<script_id>
         }
}

body

contextId 
the id of the context this break occurred in
debuggerStatement 
boolean describing whether the break was due to a debugger; statement being encountered
threadId 
the id of the thread the break occurred in
step 
the kind of the step, one of in, out, next, suspend (only included if the event was due to a step)
lineNumber 
the line number the break occurred on
scriptId 
the id of the script the break occurred in

example

A real life example of the break event is: 

143
\r\n
{
  "type":"event",
  "seq":17,
  "event":"break",
  "body":{
          "contextId":0,
          "debuggerStatement":false,
          "threadId":1,
          "step":"in",
          "lineNumber":2,
          "scriptId":1}
}

exception

An exception event is sent when a thrown exception is not caught. The event will be sent only if an ExceptionRequest as been registered.

The general form of the exception event is: 

<content_length>
\r\n
{
   "type":"event",
   "seq":<packet_sequence>,
   "event":"exception",
   "body":{
           "contextId":<context_id>,
           "threadId":<thread_id>,
           "message":<message>,
           "lineNumber":<line_number>,
           "scriptId":<script_id>
          }
}

body

contextId 
the id of the context this exception belongs to
threadId 
the id of the thread this exception was thrown from
message 
the message (if any) from the underlying exception
lineNumber 
the line in source the exception was thrown from
scrtipId 
the id of the script if exception was thrown from

example 

163
\r\n
{
  "type":"event",
  "seq":35,
  "event":"exception",
  "body":{
          "contextId":0,
          "threadId":1,
          "message":"MINE (\/home\/mrennie\/scripts\/scr.js#2)",
          "lineNumber":2,
          "scriptId":2
         }
}

script

A script event is sent when a script has been compiled in the remote interpreter - also referred to as being "loaded" in the interpreter.

This event will be sent only if a ScriptLoadRequest has been registered.

The general form of the script event is: 

<content_length>
\r\n
{
  "type":"event",
  "seq":<packet_sequence>,
  "event":"script",
  "body":{
          "contextId":<context_id>,
          "threadId":<thread_id>,
          "scriptId":<script_id>
         }
}

body

contextId 
the id of the context the script belongs to
threadId 
the id of the thread the script was loaded in
scriptId 
the unique id of script

example

A real life example of the script event is: 

91
\r\n
{
  "type":"event",
  "seq":13,
  "event":"script",
  "body":{
          "contextId":0,
          "threadId":1,
          "scriptId":1
         }
}

thread

The thread event is sent when a new context (thread) of execution is created in the remote interpreter. The event will be sent only if a ThreadEnterRequest or a ThreadExitRequest has been registered.

The general form of the thread event is: 

<content_length>
\r\n
{
  "type":"event",
  "seq":<packet_sequence>,
  "event":"thread",
  "body":{
          "threadId":<thread_id>,
          "type":<thread_event_type>
         }
}

body

threadId 
the id of the thread the event applies to
type 
the type of the thread event, one of enter or exit

example

A real life example of the thread event is: 

78
\r\n
{
  "type":"event",
  "seq":7,
  "event":"thread",
  "body":{
          "threadId":0,
          "type":"enter"
         }
}

vmdeath

The vmdeath event is sent when the remote interpreter is about to die / disconnect. This event is sent on a best-effort basis, meaning it is not guaranteed the event can be received, if for example, the communication channel has been interrupted before the event has been sent. The event will be sent only if a VMDeathRequest has been registered.

The general form of the vmdeath event is: 

<content_length>
\r\n
{
  "type":"event",
  "seq":<packet_sequence>,
  "event":"vmdeath",
  "body":{}
}

body

The body of this event is not necessarily present and is always empty when present.

example

A real life example of the vmdeath event is: 

52
\r\n
{
  "type":"event",
  "seq":7,
  "event":"vmdeath",
  "body":{}
}

Requests

breakpoint

The breakpoint request is sent from the client to the remote interpreter to retrieve a specific breakpoint. If communication is successful a corresponding breakpoint response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"breakpoint",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "breakpointId":<breakpoint_id>
              }
}

arguments

breakpointId 
the id of the breakpoint to look up

example

A real life example of the breakpoint request is: 

81
\r\n
{
  "command":"breakpoint",
  "type":"request",
  "seq":14,
  "arguments":{
               "breakpointId":1
              }
}

breakpoints

The breakpoints request is sent from the client to the remote interpreter to retrieve all breakpoints set in the remote interpreter. If communication is successful a corresponding breakpoints response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"breakpoints",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments, and any set arguments will be ignored.

example

A real life example of the breakpoints request is: 

66
\r\n
{
  "command":"breakpoints",
  "type":"request",
  "seq":15,
  "arguments":{}
}

clearbreakpoint

The clearbreakpoint request is sent from the client to the remote interpreter to remove a specific breakpoint. If communication is successful a corresponding clearbreakpoint response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"clearbreakpoint",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "breakpointId":<breakpoint_id>
              }
}

arguments

breakpointId 
the id of the breakpoint to clear

example

A real life example of the clearbreakpoint request is: 

86
\r\n
{
  "command":"clearbreakpoint",
  "seq":77,
  "type":"request",
  "arguments":{
               "breakpointId":3
              }
}

connect

The connect request is made from the client to the remoter interpreter to establish a connection. If communication was successful a corresponding connect response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"connect",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments, and any set arguments will be ignored.

example

A real life example of the connect request is: 

62
\r\n
{
  "command":"connect",
  "type":"request",
  "seq":27,
  "arguments":{}
}

context

The context request is sent from the client to the remote interpreter to ask for the context of a specified thread. If communication is successful a corresponding context response is sent back from the remote interpreter.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"context",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "threadId":<thread_id>
              }
}

arguments

threadId 
the id of the thread to get the context for

example

A real life example of the context request is: 

74
\r\n
{
  "command":"context",
  "type":"request",
  "seq":20,
  "arguments":{
               "threadId":1
              }
}

continue

The continue request is sent from the client to the remote interpreter to indicate that the interpreter should resume execution of a step, thread, or entire interpreter. This request has no effect if the remote interpreter is not currently in a suspended state. If communication is successful a corresponding continue response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"continue",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "threadId":<thread_id>,
               "step":<step_kind>
              }
}

arguments

This request can optionally take arguments to describe a step operation that should occur after the continue.

threadId 
the id of the thread to step within
step 
the kind of the step operation desired, one of in, out, next

example

A real life example of the continue request is: 

63
\r\n
{
  "command":"continue",
  "seq":32,
  "type":"request",
  "arguments":{}
}
Another real life example of the continue request using optional arguments for step is: 
86
\r\n
{
  "command":"continue",
  "seq":8,
  "type":"request",
  "arguments":{
               "threadId":1,
               "step":"in"
              }
`}

dispose

The dispose request is sent from the client to the remote interpreter to shut down the interpreter. If communication is successful a corresponding dispose response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"dispose",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments and any set arguments will be ignored.

example

A real life example of the dispose request is: 

62
\r\n
{
  "command":"dispose",
  "seq":42,
  "type":"request",
  "arguments":{}
}

evaluate

The evaluate request is sent from the client to the remote interpreter to evaluate a given script snippet. If communication is successful a corresponding evaluate response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"evaluate",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "expression":<expression>,
               "contextId":<context_id>,
               "frameId":<frame_id>,
               "threadId":<thread_id>
              }
}

arguments

expression 
the expression you want to evaluate
contextId 
the id of the owning context
frameId 
the id of the stack frame to perform the evaluation in
threadId 
the id of the thread the frame belongs to

example

A real life example of the evaluate request is: 

121
\r\n
{
  "command":"evaluate",
  "seq":12,
  "type":"request",
  "arguments":{
               "expression":"this",
               "contextId":0,
               "frameId":0,
               "threadId":0
              }
}

frame

The frame request is sent from the client to the remoter interpreter to ask for a specific stack frame. If communication is successful a corresponding frame response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"frame",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "frameId":<frame_id>,
               "threadId":<thread_id>
              }
}

arguments

frameId 
the id of the frame to look up
threadId 
the id of the thread to look the frame up in

example

A real life example of the frame request is: 

85
\r\n
{
  "command":"frame",
  "seq":118,
  "type":"request",
  "arguments":{
               "frameId":3,
               "threadId":1
              }
}

frames

The frames request is sent from the client to the remote interpreter to retrieve stack frames for a thread. If communication is successful a corresponding frames response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"frames",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "threadId":<thread_id>
              }
}

arguments

threadId 
the id of the thread to get the frames for

example

A real life example of the frames request is: 

73
\r\n
{
  "command":"frames",
  "seq":93,
  "type":"request",
  "arguments":{
               "threadId":1
              }
}

lookup

The lookup request is sent from the client to the remote interpreter to look up a given id - which could be any valid element id (frame id, script id, etc). If communication is successful a corresponding lookup response is sent back from the remoter interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"lookup",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "ref":<ref_id>,
               "frameId":<frame_id>,
               "threadId":<thread_id>
              }
}

arguments

ref 
the unique handle for this look up
frameId 
the id of the frame to perform the look up in
threadId 
the id of the thread that owns the stack frame

example

A real life example of the lookup request is: 

97
\r\n
{
  "command":"lookup",
  "seq":131,
  "type":"request",
  "arguments":{
               "ref":0,
               "frameId":3,
               "threadId":1
              }
}

script

The script request is sent from the client to the remote interpreter to retrieve a script. If communication is successful a corresponding script response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"script",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "scriptId":<script_id>
              }
}

arguments

scriptId 
the id of the script to look up. This id can be acquired from a scripts request.

example

A real life example of the script request is: 

73
\r\n
{
  "command":"script",
  "seq":36,
  "type":"request",
  "arguments":{
               "scriptId":1
              }
}

scripts

The scripts request is sent from the client to the remoter interpreter to retrieve the complete listing of scripts loaded in the interpreter. If communication was successful a corresponding scripts response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"scripts",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments, and any set arguments will be ignored.

example

A real life example of the scripts request: 

62
\r\n
{
  "command":"scripts",
  "type":"request",
  "seq":28,
  "arguments":{}
}

setbreakpoint

The setbreakpoint request is sent from the client to the remote interpreter to set a breakpoint at a given location. If communication is successful a corresponding setbreakpoint response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"setbreakpoint",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "condition":<condition>,
               "line":<line_number>,
               "scriptId":<script_id>
              }
}

arguments

scriptId 
the id of the script to set the breakpoint in
line 
the line number to set the breakpoint on
condition 
an optional condition to evaluate when the breakpoint is hit to determine if the breakpoint should suspend or not

example

A real life example of the setbreakpoint request is: 

107
\r\n
{
  "command":"setbreakpoint",
  "seq":51,
  "type":"request",
  "arguments":{
               "condition":null,
               "line":10,
               "scriptId":1
              }
}

suspend

The suspend request is sent from the client to the remote interpreter to suspend execution of a thread. The request has no effect if the thread is not in a running state. If communication is successful a corresponding suspend response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"suspend",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "threadId":<thread_id>
              }
}

arguments

threadId 
the id of the thread to suspend

example

A real life example of the suspend request is: 

62
\r\n
{
  "command":"suspend",
  "seq":50,
  "type":"request",
  "arguments":{
               "threadId":1
              }
}

thread

The thread request is sent from the client to the remote interpreter to retrieve a thread. If communication is successful a corresponding thread response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"thread",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{
               "threadId":<thread_id>
              }
}

arguments

threadId 
the id of the thread to retrieve

example

A real life example of the thread request is: 

73
\r\n
{
  "command":"thread",
  "seq":49,
  "type":"request",
  "arguments":{
               "threadId":1
              }
}

threads

The threads request is sent from the client to the remote interpreter to retrieve all threads that currently exist in the interpreter. If communication is successful a corresponding threads response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"threads",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments, and any set arguments will be ignored.

example

A real life example of the threads request is: 

62
\r\n
{
  "command":"threads",
  "seq":40,
  "type":"request",
  "arguments":{}
}

version

The version request is sent from the client to the remote interpreter to retrieve the version of the Rhino interpreter. If communication was successful a corresponding version response is sent back from the remote interpreter.



The form of the packet is: 

<content_length>
\r\n
{
  "command":"version",
  "type":"request",
  "seq":<packet_sequence>,
  "arguments":{}
}

arguments

This request takes no arguments, and any set arguments will be ignored.

example

A real life example of the version request is: 
62
\r\n
{
  "command":"version",
  "seq":29,
  "type":"request",
  "arguments":{}
}

Responses

breakpoint

The breakpoint response is sent from the remote interpreter to the client only if a breakpoint request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"breakpoint",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "message":<status_message>
  "body":{
          "breakpoint":{
                        "condition":<condition>,
                        "line":<line_number>,
                        "breakpointId":<breakpoint_id>,
                        "scriptId":<script_id>
                       }
         }
}


body

breakpoint 
the description of the breakpoint

breakpoint

condition 
an optional condition set on the breakpoint to be evaluated to determine if the breakpoint should suspend
line 
the line number the breakpoint is set on
breakpointId 
the unique id of the breakpoint
scriptId 
the unique id of the script the breakpoint is set in

example

A real life example of a breakpoint response is: 

181
\r\n
{
  "command":"breakpoint",
  "type":"response",
  "request_seq":30,
  "seq":31,
  "running":true,
  "success":true,
  "body":{
          "breakpoint":{
                        "condition":"1===1",
                        "line":1,
                        "breakpointId":0,
                        "scriptId":0
                       }
         }
}

A real life example of a breakpoint response for a breakpoint id that does not exist is: 

129
\r\n
{
  "command":"breakpoint",
  "type":"response",
  "request_seq":1,
  "seq":2,
  "message":"not found",
  "running":true,
  "success":false,
  "body":{}
}

breakpoints

The breakpoints response is sent from the remote interpreter to the client only if a breakpoints request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"breakpoints",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "breakpoints":[<breakpoint_id_list>]
         }
}

body

breakpoints 
the list of breakpoint ids

example

A real life example of a breakpoints response is: 

126
\r\n
{
  "command":"breakpoints",
  "type":"response",
  "request_seq":47,
  "seq":48,
  "running":true,
  "success":true,
  "body":{
          "breakpoints":[0]
         }
}

clearbreakpoint

The clearbreakpoint response is sent from the remoter interpreter to the client only if a clearbreakpoint request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"clearbreakpoint",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "breakpoint":{
                        "breakpointId":<breakpoint_id>,
                        "line":<line_number>,
                        "scriptId":<script_id>
                       }
         }
}

body

breakpoint 
the description of the breakpoint that was removed

breakpoint

breakpointId 
the id of the breakpoint that was removed
line 
the line number the breakpoint was removed from
scriptId 
the id of the script the breakpoint was removed from

example

A real life example of a clearbreakpoint response is: 

167
\r\n
{
  "command":"clearbreakpoint",
  "type":"response",
  "request_seq":77,
  "seq":84,
  "running":true,
  "success":true,
  "body":{
          "breakpoint":{
                        "breakpointId":3,
                        "line":10,
                        "scriptId":1
                       }
         }
}

connect

The connect response is sent from the remote interpreter to the client only if a connect request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"connect",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{}
}

body

The body of the response is empty.

example

A real life example of a connect response is: 

105
\r\n
{
  "command":"connect",
  "type":"response", 
  "request_seq":27,
  "seq":37,
  "running":true,
  "success":true,
  "body":{}
}

continue

The continue response is sent from the remote interpreter to the client only if a continue request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"continue",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{}
}

body

The body of the response is empty.

example

A real life example of a continue response is: 

106
\r\n
{
  "command":"continue",
  "type":"response",
  "request_seq":41,
  "seq":49,
  "running":true,
  "success":true,
  "body":{}
}

dispose

The dispose response is sent from the remoter interpreter to the client only if a dispose request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"dispose",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{}
}

body

The body of the response is empty.

example

A real life example of a dispose response is: 

105
\r\n
{
  "command":"dispose",
  "type":"response",
  "request_seq":56,
  "seq":63,
  "running":true,
  "success":true,
  "body":{}
}

evaluate

The evaluate response is sent from the remote interpreter to the client only if a evaluate request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"evaluate",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "evaluate":{
                      "ref":<ref_id>,
                      "constructorFunction":{"ref":2},
                      "prototypeObject":{"ref":3},
                      "className":"Object",
                      "properties":[<properties_list>],
                      "type":"object"
                     }
          }
}

body

evaluate 
the result of the evaluation, as an object, or null if the evaluate had no result

evaluate

ref 
the unique object handle for the evaluation result
constructorFunction 
the object handle for the constructor function for the result
prototypeObject 
the object handle for the prototype for the result
className 
the name of the class backing the result
properties 
the listing of any additional properties for the result
type 
the type of the result

example

A real life example of a evaluate response is: 

1971
\r\n
{
  "command":"evaluate",
  "type":"response",
  "request_seq":12,
  "seq":13,
  "running":true,
  "success":true,
  "body":{
          "evaluate":{
                      "ref":1,
                      "constructorFunction":{"ref":2},
                      "prototypeObject":{"ref":3},
                      "className":"Object",
                      "properties":[
                                    {"ref":6,"name":"line6"},
                                    ..<snip>..,
                                    {"ref":61,"name":"line1"}],
                      "type":"object"
                     }
          }
}

If an evaluate request is made with an expression that has no effect, the response is: 

121
\r\n
{
  "command":"evaluate",
  "type":"response",
  "request_seq":12,
  "seq":13,
  "running":true,
  "success":true,
  "body":{
          "evaluate":null
         }
}

frame

The frame response is sent from the remote interpreter to the client only if a frame request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"frame",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "frame":{
                   "contextId":<context_id>,
                   "scopeName":<scope_name>,
                   "ref":<ref_id>,
                   "threadId":<thread_id>,
                   "line":<line_number>,
                   "frameId":<frame_id>,
                   "scriptId":<script_id>
                  }
         }
}

body

frame 
the description of the stack frame

frame

contextId 
the id of the context this frame belongs to
scopeName 
not used
ref 
the number 0
threadId 
the id of the owning thread
line 
the current line number the frame is stopped at
frameId 
the unique id of the stack frame
scriptId 
the id of script the frame references

example

A real life example of a frame response is: 

200
\r\n
{
  "command":"frame",
  "type":"response",
  "request_seq":104,
  "seq":115,
  "running":true,
  "success":true,
  "body":{
          "frame":{
                   "contextId":0,
                   "scopeName":null,
                   "ref":0,
                   "threadId":1,
                   "line":3,
                   "frameId":2,
                   "scriptId":1
                  }
         }
}

frames

The frames response is sent from the remote interpreter to the client only if a frames request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"frames",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "frames":<frame_id_list>
         }
}

body

frames 
the list of unique ids for all of the frames for the given thread

example

A real life example of a frames response is: 

118
\r\n
{
  "command":"frames",
  "type":"response",
  "request_seq":101,
  "seq":111,
  "running":true,
  "success":true,
  "body":{
          "frames":[2]
         }
}

lookup

The lookup response is sent from the remote interpreter to the client only if a lookup request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"lookup",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "lookup":{
                    "ref":<ref_id>,
                    "type":<returned_element_type>,
                    "properties":[<properties_list>]
                   }
         }
}

body

lookup 
the result of the lookup

lookup

ref 
the unique handle for the lookup
type 
the type of the returned lookup
properties 
additional properties

example

A real life example of a lookup response is: 

2528
\r\n
{
  "command":"lookup",
  "type":"response",
  "request_seq":131,
  "seq":146,
  "running":true,
  "success":true,
  "body":{
          "lookup":{
                    "ref":0,
                    "type":"frame",
                    "properties":[
                                  {"ref":64,"name":"undefined"},
                                  {"ref":1,"name":"this"},
                                  ...<snip>...,
                                  {"ref":44,"name":"getClass"},
                                  {"ref":78,"name":"deserialize"},
                                  {"ref":41,"name":"unescape"},
                                  {"ref":60,"name":"Function"}
                                 ]
                   }
         }
}

script

The script response is sent from the remote interpreter to the client only if a script request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"script",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "script":{
                    "lines":[<line_number_list>],
                    "functions":[<func_name_list>],
                    "generated":<is_generated>,
                    "source":<source_string>,
                    "location":<source_uri>,
                    "properties":<properties_list>,
                    "scriptId":<script_id>
                   }
         }
}

body

script 
the description of the script

script

lines 
the valid line locations as reported by the Rhino interpreter
functions 
the list of function names reported by the Rhino interpreter
generated 
if the script was generated by the interpreter
source 
the underlying source of the script
location 
the URI location of the script
properties 
any additional properties for the script
scriptId 
the unique id of the script

example

A real life example of a script response is: 

1117
\r\n
{
  "command":"script",
  "type":"response",
  "request_seq":36,
  "seq":44,
  "running":true,
  "success":true,
  "body":{
          "script":{
                    "lines":[4,23,11,16,3,7,12,17,2,13,9,6,20,14,10],
                    "functions":["FibonacciServlet","","",""],
                    "generated":false,
                    "source":"\nfunction ...<snip>",
                    "location":"file:\/home\/mrennie\/scripts\/script.js",
                    "properties":null,
                    "scriptId":1
                   }
         }
}

scripts

The scripts response is sent from the remote interpreter to the client and only if a scripts request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"scripts",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "scripts":<script_id_list>
          }
}

body

If the request is successful, the response body will contain a single element:

scripts 
the complete listing of the ids of all of the scripts loaded in the VM.

These ids are unique for each script that is loaded in the VM and can be used to subsequently look up a script in the VM. A script id is guaranteed to be unique during the lifecycle of the VM - if the VM is restarted any held script ids cannot be guaranteed to be unique.

example

A real life example of the scripts response is: 

120
\r\n
{
  "command":"scripts",
  "type":"response",
  "request_seq":28,
  "seq":38,
  "running":true,
  "success":true,
  "body":{
          "scripts":[1,0]
         }
}

setbreakpoint

The setbreakpoint response is sent from the remote interpreter to the client only if a setbreakpoint request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"setbreakpoint",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "breakpoint":{
                        "breakpointId":<breakpoint_id>,
                        "line":<line_number>,
                        "scriptId":<script_id>
                       }
         }
}

body

breakpoint 
the handle description of the newly created breakpoint

breakpoint

breakpointId 
the unique id of the breakpoint
line 
the line number the breakpoint is on
scriptId 
the id of the script the breakpoint is on

example

A real life example of a setbreakpoint response is: 

165
\r\n
{
  "command":"setbreakpoint",
  "type":"response",
  "request_seq":51,
  "seq":58,
  "running":true,
  "success":true,
  "body":{
          "breakpoint":{
                        "breakpointId":0,
                        "line":10,
                        "scriptId":1
                       }
         }
}

suspend

The suspend response is sent from the remoter interpreter to the client only if a suspend request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"suspend",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{}
}

body

The body of the response is empty.

example

A real life example of a suspend response is: 

105
\r\n
{
  "command":"suspend",
  "type":"response",
  "request_seq":50,
  "seq":57,
  "running":true,
  "success":true,
  "body":{}
}

thread

The thread response is sent from the remoter interpreter to the client only if a thread request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"thread",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{
          "thread":{
                    "threadId":<threadId>,
                    "contexts":[<context_list>],
                    "state":<thread_state>
                   }
         }
}

body

thread 
the thread description

thread

threadId 
the unique id of the thread
contexts 
the list of contexts the thread belongs to
state 
the state of the thread - running, suspended, zombie, etc

example

A real life example of a thread response is: 

160
\r\n
{
  "command":"thread",
  "type":"response",
  "request_seq":49,
  "seq":56,
  "running":true,
  "success":true,
  "body":{
          "thread":{
                    "threadId":1,
                    "contexts":[0],
                    "state":"running"
                   }
         }
}

threads

The threads response is sent from the remote interpreter to the client only if a threads request has been made.

The form of the packet is: 

<content_length>
\r\n
{
  "command":"threads",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":<is_running>,
  "success":<success_status>,
  "body":{"threads":<thread_id_list>}
}

body

If the request is successful, the response body will contain a single element:

threads 
contains the list of threads ids of threads currently in the VM

example

A real life example of a threads response is: 

118
\r\n
{
  "command":"threads",
  "type":"response",
  "request_seq":31,
  "seq":41,
  "running":true,
  "success":true,
  "body":{"threads":[1]}}

version

The version response is sent from the remote interpreter to the client and only if a version request has been made.

The packet form is: 

<content_length>
\r\n
{
  "command":"version",
  "type":"response",
  "request_seq":<request_sequence>,
  "seq":<packet_sequence>,
  "running":true,
  "success":true,
  "body":{<version_elements>}}

body

If the request is successful, the body of the response will contain five elements with version information:

javascript.vm.version 
the version of the VM running the interpreter
javascript.vm.vendor 
the vendor of the VM
javascript.version 
the version of the interpreter being used
ecmascript.version 
the ECMA version used in the VM
javascript.vm.name 
the human-readable name of the VM

example

A real life example of the version response is: 

248
\r\n
{
  "command":"version",
  "type":"response",
  "request_seq":29,
  "seq":39,
  "running":true,
  "success":true,
  "body":{
          "javascript.vm.version":"1.6",
          "javascript.vm.vendor":"Mozilla",
          "javascript.version":"1.6",
          "ecmascript.version":"3",
          "javascript.vm.name":"Rhino"
         }
}
Retrieved from "https://wiki.eclipse.org/index.php?title=JSDT/Debug/Rhino/Rhino_Debug_Wire_Protocol&oldid=292646"

This page was last modified 19:11, 1 March 2012 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top