JEB Plugin Development Tutorial part 5/8

Development Tips

This tutorial aggregates a collection of tips that can help you during plugin development.

Logging

Creating Loggers

Creating a new logger with the JEB API is simple:

private static final ILogger logger = GlobalLog.getLogger(MyClass.class);

It is good practice to create one logger per class. Loggers can be customized one by one, or globally via the GlobalLog factory.

Using Loggers

There are several level of logs (error, warning, info, ...) and the logger methods use 2 parameters:

logger.info("Hello %s", "World");

Enabling Debug and Trace levels

By default, debug and trace logs are not displayed. You can activate them by ticking the Development mode in the Options menu:

Logging destinations

By default, JEB sends log data to the Logger view in the RCP client. Additional sinks canbe added, such as buffers or output streams. For instance, if you would like to collect all logs to a file named jeb-test-output.log in your TEMP folder, your plugin could execute the following:

String foldername = System.getProperty("java.io.tmpdir");
File folder = foldername != null ? new File(foldername): TestData.getTestDataRoot();
File file = new File(folder, "jeb-test-output.log");
GlobalLog.addDestinationStream(new PrintStream(file));

Be careful, GlobalLog is a global factory object, that impacts the entire application.

Debugging

If you are familiar with Eclipse and development tools in general, you know how useful proper debugging facility are: the program can be stopped and paused, current variables can be examined, etc. It is especially handy when troubleshooting a corner-case problem in your plugin.

JEB can be debugged using a method called remote debugging. What you need to do is:

Debugging setup: step-by-step

Start JEB using the following command-line from your JEB base directory:

Don't forget to replace XXXXXXXXXXXX by your current Equinox package version.

JEB is not started yet: it is waiting for a debugger connection on port 8001

Go to Eclipse:

JEB should be launched and you may be able to stop when putting breakpoints in code.

In practice, the true entry-point of a plugin is its no-argument constructor. You may decide to place a breakpoint there. You may also choose to stop in the canIdentify() method, which is appropriate for processor plugins such as this sample JavaScript parser.

Launching several instances

JEB provides a fully customizable workspace area. Panels can be adjusted, stacked, minimized, expanded, etc. That data is persisted into a workspace folder.

You may have a need to to launch several instances of JEB, for instance because you have long processing on a first instance, and would like to continue investigating another task. If you try to launch a second instance, you are likely to see this error message:

This indicates a workspace conflict.

It is possible to launch a second (or more) instances of the JEB client by appending the -data @none parameters to the command line. Here, @none indicates that no workspace data shall be used or saved. (You may decide to persist that secondary workspace by providing a folder instead of @none.)

If you wish to modify your startup scripts to never record workspace layout data, and therefore have the ability to conveniently start as many instances of JEB as you'd like, here are the modifications to do:

On Linux/Mac OS:

$JAVA -jar $SCRIPTDIR/bin/cl/jeb.jar $@
to 
$JAVA -data @none -jar $SCRIPTDIR/bin/cl/jeb.jar $@

On Windows:

%JAVA% -jar "%~dp0bin\cl\jeb.jar" %*
to
%JAVA% -data @none -jar "%~dp0bin\cl\jeb.jar" %*

Next: Part 6