Skip to content

start:

How does OpenOffice.org and the IDE cooperate (from user perspective)?

What technical issues have to be looked at for this to be achieved?

The current situation (and possible future improvements)

Let us examine the scenario where the user has received a document containing a broken Java script (assume that we've got the binding of Java scripts working in a similar way to StarBasic scripts, and that the Java runtime is initiated in the same way as for Java UNO components). We shall examine the steps needed to debug the script. The sections in bold are possible suggestions as to how this process could be made easier for the developer.

  1. The JVM being run in-process within OpenOffice.org must must be started with the appropriate arguments to enable a JPDA connection. ( -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n). These are currently stored in the usr/config/javarc (or java.ini on Windows), and there appears to be no means of setting them via the UI.
    These settings should be moved to the registry if possible. They should be configurable via the UI, with perhaps, a checkbox to simplify the process (ie. "enable for remote debugging"). The user should not have to restart OpenOffice.org for these to take effect.
  2. The user must then launch NetBeans. They can then (via the Debug->Attach dialog) make a JPDA connection back to OpenOffice.org's JVM.
    The user should be able to specify the IDE location through the OpenOffice.org UI, and able able to launch the IDE from OpenOffice.org. In the case of NetBeans, we should provide a module for NetBeans that established a control connection (secure) back to OpenOffice.org, to allow for the exchange of the JPDA settings. The module should then automatically attempt to make the JPDA connection.
  3. The user must then load the document into OpenOffice.org, mount the document within NetBeans, and open up the Java source for the script in NetBeans, and set whatever necessary breakpoints.
    The user should be able to simple load the document in to OpenOffice.org, and mark the session as a debug session (mark the particular script for debugging, or click on a button "Load into IDE"). This should either communicate the documents location, or alternatively the script(s) sources to NetBeans. In the case where the documents location is transmitted, NetBeans should then automatically mount the doc & load up the scripts source code. Alternatively, the direct communication of source could be achieved by writing a filesystem module that utilised the connection established above. In addition, this should set, by default, a breakpoint at the entry point (normally a method) to the script. the can be achieved either by OpenOffice.org using the JVMDI APIs, or through communication to NetBeans, and use of the Open IDE APIs (see below for more details).
  4. At this point the user can do whatever action leads to triggering the script, and proceed to debug the code within NetBeans.
  5. Having identified the problem and modified the code accordingly, the user must now re-embed the code into the document. Currently, they must save the changes into the documents zip file within NetBean, and re-load it within OpenOffice.org for the changes to take effect, and to verify the fix.
    It should also be possible to write a module for NetBeans to enable it to push the changes back to OpenOffice.org, and then have OpenOffice.org save the modified document (including and modifications to the document's content in addition to the modifications to the script.

Debugging

Currently within forte, we can do:

  1. Variable Evaluation
  2. Start/Stop/Pause Debugging
  3. Step by Step Execution
  4. Specifying the settings for the JPDA attachment to the OpenOffice.org JVM
  5. Programmatically attaching JDPA to the Running JVM
  6. Programmatically starting the JPDA from NetBeans or OpenOffice.org
More info on attaching to the JVM in NetBeans is available at NetBeans JPDA Module
The ConnectPanel is good place to look on how to attach JPDA to the JVM

From Jan Jancura of NetBeans/NetBeans

JPDA debugger is default debugger "by default", so I am not sure what do you exactly want, but:
  1. your module must depend on JPDA module & Java module
  2. you should find JPDADebuggerType instance. For example:
    dt = (JPDADebuggerType)Lookup.getDefault().lookup(JPDADebuggerType.class);
  3. call setDebugger (debuggerType) for class:
    nb_all\java\src\org\netbeans\modules\java\settings\JavaSettings.java ((JavaSettings) JavaSettings.findObject (JavaSettings.class, true)).setDebugger (dt);

End quote

Having Breakpoints at the start of a method

To set a breakpoint in OpenOffice.org at *just* the method level, is a matter of harnessing the OpenOffice.org JVM's Debug Interface, the JVMDI will allow a developer to set breakpoints on methods without the use of an IDE. The method in JVMDI is SetBreakPoint(jclass clazz, jmethodID method, jlocation location) location is obtainable through the GetMethodLocation() method.

More information on this is available at JVMDI Reference

Setting a breakpoint on a method can also be done through the Open APIs in NetBeans, look at NetBeans Open APIs for more information.

Storage

Storage depends on the structure of the stored scripts within the document, currently, we can place Java source files into a OpenOffice.org document, and view and edit the source in forte. The problem arises when the scripts are in a jar file in the OpenOffice.org document, the content of the jar file is inaccessible to forte. However, this could be over come, through development of a module of forte for the forte filesystem, which would recursively "look into" zip/jar files.

Dynamically, "mount and umounting" filesystems is achievable through the forte filesystem API, when editing scripts that OpenOffice.org is currently using, a forte module developed for scripting could possible tell OpenOffice.org through IPC that the scripts have been modified and to reload the scripts.

One possible problem with Storage, is when OpenOffice.org launches the IDE, and it wants the IDE to edit the scripts.

As the script is in memory and the contents of the document stored may be edited, this could have potential problems, like if the IDE edits the script through the filesystem, and saved the script in the document, OpenOffice.org would not get the edits, it has made into the document.

We came up with two probable solutions to these problems

OpenOffice.org NetBeans using filesystem
NetBeans accesses scripts through the filesystem

With this solution, when a user wants to edit a script, OpenOffice.org must put the script in some temporary file location on the filesystem, and tell NetBeans over IPC the location of the script. When NetBeans is finished editing the script and has saved it to the temporary location, it must inform OpenOffice.org over IPC that the editing of the script has finished and that the script is ready to be used.

OpenOffice.org NetBeans Serialising IPC
OpenOffice.org and NetBeans share content over IPC serializing the scripts

In this solution, OpenOffice.org serializes the scripts and passes them over IPC to NetBeans, where NetBeans deserializes the content through a filesystem module, when NetBeans has finished with the content, it will serialize it and send it back to OpenOffice.org which can use it then.

Our preferred solution is the second solution, it is a much cleaner solution, has everything is held in memory, there is multiple accesses to the filesystem. Also, if in the first solution, the script got saved back to the OpenOffice.org file and there were edits on the content of the file, the edits might not be saved.

With the second solution, one process, OpenOffice.org is able to access the actual file, NetBeans is only able to access the serialized content.

Links