Server side

First thing we need is a small utility script called bugzilla-submit which can be found in BUGZILLA DIRECTORY/contrib/bugzilla-submit folder. It's simple command line interface for submitting new bugs. This script reads .netrc file in the home directory (/var/www in our case) which must contain bugzilla system credentials:

machine "http://bugzilla.our-company.com"
login <an email address of bugzilla user>
password <password>


Second thing we need is to create a simple php script that will live on some publicly accessible server and will process POSTed bugs and submit them using the mentioned utility into bugzilla server (which may or may not be on the same machine). Basic skeleton of such script:

As you can see, the script is very simple as it allows only bug description to be modified (by our Eclipse plugin reporting system) and other fields are hard coded. It also isn't secured in any way so anyone who knows URL of the script (and guesses the format of POST request) can submit bugs!

There are many possibilities of how to secure it (e.g. some kind of one time passwords, https, limiting the number of allowed submit from one IP address etc.).

Client side

The third (and last) thing is the code in our Eclipse plugin that handles exceptions and asks user if he wants to report them. We do this simply by listening to workspace log events and reporting (or asking user if he wants to report) if one of the following conditions holds:

1. The plugin where an error occured is ours
2. The exception stacktrace contains our class

We consider plugin or class "ours" if its name starts with "com.our-company.productname". The following code must be run at startup (see how to do it):

And that's probably all

• Custom event listeners
• Soft reference cache
• Preventing memory leaks when using cached objects & listeners

Creating and using custom event listeners

Listeners are great when it comes to the communication of objects that should stay decoupled to a high degree. They are used just about everywhere (e.g. SWT) and sometimes it would be nice to add custom listeners to our objects. And that's showtime for ListenerList class from org.eclipse.core.runtime package. It is fully thread-safe list designed for storing lists of listeners (optimized for frequent reads and infrequent writes).

Typical custom class would contain something like:

With IMyListener being:

So when our event happens in our class ClassWithListeners we notify all listeners (that have been previously registered by addMyEventListener()) by calling fireMyEvent().

Its always good practice to unregister by calling removeMyEventListener() when we are no longer interested in the event or when the owning objects are going to be disposed. To see how to achieve this automatically read on.

Creating soft reference cache

Common scenario is to have some objects that are very expensive (time consuming) to create but once created they can be used many times as they don't change (or at least not too often).

Such objects are ideal candidates for some kind of caching. Naive approach is to create these objects at the start of program and keep them in memory until the end of the program. It sure works but the price of slower program startup and bigger memory footprint may be too high.

First improvement would be lazy initialization (do not create object until first needed). Second and here described improvement is soft reference caching whose main advantage is that cached objects can be garbage-collected when needed (to release memory for other objects) and recreated when they are to be used again.

The simplest cache might look like this:

Of course, there is room for improvements (generics, cache entries invalidation etc.). Without much trouble a whole generic cache can be written.

Preventing memory leaks when using cached objects & listeners

If we combine both above described steps and cache objects that register some listeners to other objects we might end up having memory leaks in our application. Sample scenario:

The problem with this scenario is that ExpensiveObject will never be garbage-collected even if memory runs low. That's because ObjectThatLivesTheWholeApplicationLife holds instance of IMyListener that holds strong (non garbage-collectable) reference to an instance of ExpensiveObject.

Possible way to solve it is to wrap IMyListener into weak reference (which is garbage-collectable if there are no other strong references to the object). Moreover the wrapper will automatically unregister event handler if its owner (ExpensiveObject) is disposed.

Such wrapper could look like this:

And the usage could be either on the side of ExpensiveObject:

or on the side of ObjectThatLivesTheWholeApplicationLife:

• How to get the index of selected column in TableViewer
• How to create and use TreeViewer with multiple equal items

Getting the index of selected column in TableViewer

Let's say we want do some action when user double clicks on the row in TableViewer. Achieving this is easy, the code might look like this:

If we need to know not only which row but also which exact column was double clicked, things get more complicated then that because there doesn't seem to be direct standard support for this:

Creating TreeViewer with multiple equal items

There are situations where we want a TreeViewer to contain multiple items that are equal (i.e. X.equals(Y) returns true for items X, Y).

An example of such situation would be tree containing classes (as root nodes) with every class having its super class as a child node. Then it is possible to imagine having class A as a root node and class B as its child node (which means class A extends class B) - but class B might be also root node (with another class C as a child).

We can see that class B is contained twice in the TreeViewer and this may lead to problems (one of which is incorrectly working treeViewer.setSelection(B) - it will randomly select one of two B class nodes depending on circumstances).

The solution consists of these steps:

1. Use ITreePathContentProvider instead of commonly used ITreeContentProvider content provider
3. Before selecting the item in tree do treeViewer. setSelection(null) first - this is needed to get around what I am not sure is feature or bug - there is some internal hash table used and if currently selected item has the same hashCode() as the new one, the new selection is ignored. Setting null before real selection helps.
4. For selecting item in tree use setSelection(treePath) (instead of setSelection(item)) - simply put, TreePath is path consisting of items from root to item we want to select (inclusive)

• Dialogs
• Compound document operations
• Markers

Simple dialogs

- also see JavaDoc

Sometimes there is need to show simple messages to user. There are some nice functions in MessageDialog class. Example of an error message:

Example of confirmation dialog (with yes/no buttons):

More complex dialogs

To create more complex dialogs simply extend the org.eclipse.jface.dialogs.Dialog class and:

• override createDialogArea() and create dialog's controls there
• override configureShell() and set dialog's title there
• override createButtonsForButtonBar() and create dialog's buttons there using createButton()
• override buttonPressed() and setReturnCode() according to pressed button (also close() dialog if needed)
• use setBlockOnOpen(true) in constructor for creating modal dialog

Compound document operations

To make Eclipse consider more operations as one compound operation (useful for more intuitive undo etc.) use the following code:

Markers

- also see Tutorial, FAQ, FAQ2, FAQ3

Markers are means of highlighting parts of text in editors and can be also shown in Problems view. For creating custom markers define it in plugin.xml first:

Next step is to create marker:

The above code creates marker for the whole line. To have more precious positioning add:

To get all markers of our newly specified type (and subtypes) for specified IResource (e.g. IFile) use:

Finally, to delete all markers of specified type use:

If you create editor with custom SourceViewerConfiguration be sure to extend TextSourceViewerConfiguration to get marker tooltips support for free (otherwise your marker tooltips won't be displayed without some additional coding).