Aside of the use of a different scripting language, this example differs completely from the Ruby one by its context of execution: it will be integrated into Eclipse and called directly from its user interface (using Eclipse Monkey as the glue).

The example will:

1. ask graphically the user for a logging level
2. update all the JVM’s loggers with this level
3. display all the loggers of the JVM

in 50 lines of code.

This example is simple but it implies several interesting steps:

• connect to a JMX Server
• retrieve a MBean
• retrieve value of MBean attributes
• invoke operations on the MBean

There are many use cases where you have to perform theses steps in repetition. It’s tedious to do that in a JMX console (e.g. jconsole or eclipse-jmx) and most of the time, it is not worth writing a Java application.

These use cases beg to be scripted.

We will again use jconsole as our managed java application (see this previous post to start jconsole with all System properties required to manage it remotely).

To run the example:

1. install Eclipse Monkey
2. Make sure that Eclipse is running on Java 1.5 or above
3. copy the script just below and save it as logging_change_level.js in the scripts directory of an Eclipse project
4. click on Scripts > Logging > Change level in Eclipse menu
5. follow the instruction to install the required DOM
   • only the JMX Monkey feature is required
6. restart Eclipse
7. click on Scripts > Logging > Change level
8. in the dialog, input the logging level
9. all the loggers have been updated with the given level

logging__change__level.js

/*
 * Menu: Logging > Change level
 * DOM: http://eclipse-jmx.googlecode.com/svn/trunk/net.jmesnil.jmx.update/net.jmesnil.jmx.monkey.doms
 */
 
function main() {
   mbsc = jmx.connect("localhost", 3000)
   logging = mbsc.getMBean("java.util.logging:type=Logging")
 
   level = ask_level()
   set_all(mbsc, logging, level)
   text = "All loggers are set to " + level + "\n\n"
   text += logger_levels(mbsc, logging)
   show(text)
}
 
function logger_levels(mbsc, logging) {
   var out = ""
   for each(loggerName in logging.LoggerNames) {
       lvl = mbsc.invoke(logging, "getLoggerLevel",
            [loggerName],
            ["java.lang.String"]);
       out += loggerName + " is at " + lvl + "\n"
   }
   return out
}
 
function set_all(mbsc, logging, level) {
   for each(loggerName in logging.LoggerNames) {
       mbsc.invoke(logging, "setLoggerLevel",
            [loggerName, level],
            ["java.lang.String", "java.lang.String"])
   }
}
 
function ask_level() {
   dialog = new Packages.org.eclipse.jface.dialogs.InputDialog(
          window.getShell(), 
          "Logging Level",
          "Which level? (SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST)",
          "INFO", null)
   result = dialog.open()
   if (result == Packages.org.eclipse.jface.window.Window.OK) {
       return dialog.getValue()
   }
}
 
function show(text) {
   Packages.org.eclipse.jface.dialogs.MessageDialog.openInformation(
           window.getShell(),
           "Update Logging",
           text
       )
}

code walkthrough

The main() function of the script is:

function main() {
  mbsc = jmx.connect("localhost", 3000)
  logging = mbsc.getMBean("java.util.logging:type=Logging")
 
   level = ask_level()
   set_all(mbsc, logging, level)
   text = "All loggers are set to " + level + "\n\n"
   text += logger_levels(mbsc, logging)
   show(text)
}

where

• mbsc = jmx.connect("localhost", 3000) creates a mbsc object connected to a local JMX server using the standard JMX Service URL.
• logging = mbsc.getMBean("java.util.logging:type=Logging") creates a logging object representing the LoggingMXBean used to manage the JVM logging.
• level = ask_level() opens an Eclipse input dialog where you can input the logging level and returns it as a String.
• set_all(mbsc, logging, level) sets all the loggers at the given level
• text += logger_levels(mbsc, logging) returns a String representation of all the loggers and their level
• show(text) opens an Eclipse message dialog

The interesting methods are logger_levels() and set_all(). In both methods, we retrieve an attribute of a MBean and invoke an operation.

Let’s focus on set_all():

function set_all(mbsc, logging, level) {
   for each(loggerName in logging.LoggerNames) {
      mbsc.invoke(logging, "setLoggerLevel",
            [loggerName, level],
            ["java.lang.String", "java.lang.String"])
   }
}

logging represents a MBean (it is not a “real” MBean, more on that later) and mbsc represents a MBeanServerConnection (but it is not a “real” MBeanServerConnection, more on that later).
logging.LoggerNames returns the value of the LoggerNames attribute of the MBean (note that the first letter must be in upper case) which is an array of strings.
For each element of this array, we invoke the setLoggerLevel operation using mbsc.invoke().
This method is very similar to the “real” MBeanServerConnection.invoke() method:

1. something representing a MBean (instead of an ObjectName)
2. the MBean operation name
3. the parameters of the operation
4. the types of the parameters

jmx: an Eclipse Monkey DOM

What do I mean when I write that logging is not the “real” LogginMXBean and that mbsc is not the real MBeanServerConnection?

This 2 types of objects are created by the jmx object in the main() method. This jmx object is in fact an Eclipse Monkey DOM that is contributed by the plug-in listed in the DOM directive at the top of the script:

DOM: http://eclipse-jmx.googlecode.com/svn/trunk/net.jmesnil.jmx.update/net.jmesnil.jmx.monkey.doms

This plug-in was included in the “JMX Monkey” feature which was installed the first time you ran this script.

The jmx DOM has a single method connect(host, port) which connects to a JMX Server using the standard JMX Service URL.
The object returned by this method is a ScriptableMBeanServerConnection. This class encapsulates the “real” MBeanServerConnection (still available using the getObject() method) but only exposes its invoke().

It also exposes a getMBean() method which returns a ScriptableMBean. In turn this class exposes the attributes of the MBean as JavaScript attributes.

To sum up, these are the operations you can perform using the jmx DOM:

• connect to a JMX server: mbsc = jmx.connect(host, port)
• get a mbean: mbean = mbsc.getMBean(objectName)
• get the value of a mbean attribute: val = mbean.AttributeName
• get the “real” mbean server connection and use it: objectNames = mbsc.getObject().queryNames(name, query)
• invoke an operation on a mbean: mbsc.invoke(mbean, operation, params, param_types)

Conclusion

This script example is simple but quite interesting thanks to its integration with Eclipse.

I believe there is an use for such scripts: repeatable management operations that needs to be tweaked from time to time. It’s tedious to do that with a GUI and it’s even more tedious to write Java applications to do so.

Last year, during EclipseCon’06, I blogged about an use case for scripting a RCP application using Eclipse Monkey. This is a concrete example: I’m using eclipse-jmx to manage Java applications that I develop. When I realize that I perform the same kind of management task, I write a monkey script which automates it.

Next time, you have to perform the same operation on many MBeans or many operations on the same MBean but you think it is not worth to write a Java application to automate it, ask yourselves if it can not be simply automated by a script such as the one in this post.

It shows only the extensions matching the filter text (and also displays the extensions categories).

Since this screenshot was from Eclipse 3.3M1 New & Noteworthy, I thought that this filter was not available for Eclipse 3.2 (or that it was specific to PDE).
It turns out that I was wrong, it works on Eclipse 3.2, and it takes only 2 lines to add such behavior to any TreeViewer using a PatternFilter and a FilteredTree (which are from the org.eclipse.ui.workbench plug-in).

Plain Old TreeViewer

The code to create the TreeViewer is straightforward:

public void createPartControl(Composite parent) {
    ...
    viewer = new TreeViewer(parent, SWT.MULTI | SWT.H_SCROLL | SWT.V_SCROLL);
    ...
}

which, in eclipse-jmx, gives:

PatternFilter & FilteredTree

To filter the tree’s nodes, the code to change is minimal:

public void createPartControl(Composite parent) {
    ...
    PatternFilter patternFilter = new PatternFilter();
    final FilteredTree filter = new FilteredTree(parent, SWT.MULTI
            | SWT.H_SCROLL | SWT.V_SCROLL, patternFilter);
    viewer = filter.getViewer();
    ...
}

With these 2 lines, a filter widget is displayed on top of the tree and the tree’s nodes are automatically filtered based on the filter text:

Screenshot has been taken on Eclipse 3.3M5 which uses native search widgets (if one is available) to display the filter control. It works also on Eclipse 3.2 but does not look so good.

By default, PatternFilter will display any nodes of the Tree whose label matches the filter text. By extending it, it is very simple to have more complex filter matching algorithm.
It is the case in eclipse-jmx: it displays any node whose descendant’s leaves have an ObjectName which matches the filter text.

Kudos to the workbench team for this little UI nugget!

However, by browsing the mailing list of the Equinox (Eclipse’s OSGi implementation), I discovered a cool new project in the Equinox incubator: Resources Monitoring.

Its mission statement?

To provide a framework for monitoring resources that are contributed by bundles installed on the host machine. The term ‘resources’ is used to describe something as specific as a single object or something as abstract as an OSGI bundle.

It seems to use JMX to manage the resources and to provide both the server and the client code to manage the resources.

Definitively worth a look…

It is a simple outliner which reads and writes OPML files. Each OPML file is opened in an Eclipse Editor. You can navigate the outliner, indent/outdent the outlines, create new outlines and edit them.
To toggle between the edition and the navigation modes, you can use the ESC key (like in vi).

The code is pre-pre alpha (hence the 0.1.1 version) and a lot of essential features are missing:

• no copy/paste
• The OPML parser is home-made and parses only a subset of OPML 2.0 (but at least, I can read some OPML 2.0 examples such as states.opml)
• I pretty sure that the generated OPML is not valid

The fun part of the application is the OutlinerEditor. Each OutlinerEditor is composed of a TreeViewer which displays the outline. The TreeViewer is not editable but each cell of the tree can be edited in place (a la SWT snippet #111).

I released this project on Google Code’s project hosting under the Apache License 2.0 and created a corresponding web site to complement the project home. You can check it out using Subversion but to make it simpler to check out, you can import in your workspace the Outliner Team Project Set (provided you have a Subversion plug-in like Subclipse). I don’t plan to work extensively on this application but I thought it could be of some interest for new Eclipse RCP developers.

I developped the application on Mac OS X and had the bad surprise to see that the application is not working properly on Linux because I can’t navigate the tree with the arrow keys (see issue #3). It seems to be a “bug” in SWT since I can’t navigate with the arrow keys in SWT snippet #111 either. Though I’m not sure this is a SWT bug or a platform specific behavior…

Let’s say that you have an action which creates a new resource and you want to notify views that they have to show this resource.

The key interface is ISetSelectionTarget. If your views respond to this interface (by implementation or adaptation), they can then receive a selectReveal(ISelection selection) message.

For example, one of my view implements ISetSelectionTarget and defines the method:

    public void selectReveal(ISelection selection) {
       StructuredSelection ssel = convertSelection(selection);
       if (!ssel.isEmpty()) {
          viewer.getControl().setRedraw(false);
          viewer.setSelection(ssel, true);
          viewer.getControl().setRedraw(true);
       }
    }

How do you send this selectReveal() message from your action?
An example is found in the JDT, in the org.eclipse.ui.wizards.newresource.BasicNewResourceWizard class:

  public static void selectAndReveal(IResource resource, IWorkbenchWindow window) {
    // validate the input
    if (window == null || resource == null)
        return;
    IWorkbenchPage page = window.getActivePage();
    if (page == null)
        return;

    // get all the view and editor parts
    List parts = new ArrayList();
    IWorkbenchPartReference refs[] = page.getViewReferences();
    for (int i = 0; i < refs.length; i++) {
        IWorkbenchPart part = refs[i].getPart(false);
        if (part != null)
            parts.add(part);
    }
    refs = page.getEditorReferences();
    for (int i = 0; i < refs.length; i++) {
        if (refs[i].getPart(false) != null)
            parts.add(refs[i].getPart(false));
    }

    final ISelection selection = new StructuredSelection(resource);
    Iterator itr = parts.iterator();
    while (itr.hasNext()) {
        IWorkbenchPart part = (IWorkbenchPart) itr.next();

        // get the part's ISetSelectionTarget implementation
        ISetSelectionTarget target = null;
        if (part instanceof ISetSelectionTarget)
            target = (ISetSelectionTarget) part;
        else
            target = (ISetSelectionTarget) part.getAdapter(ISetSelectionTarget.class);

        if (target != null) {
            // select and reveal resource
            final ISetSelectionTarget finalTarget = target;
            window.getShell().getDisplay().asyncExec(new Runnable() {
                public void run() {
                    finalTarget.selectReveal(selection);
                }
            });
        }
    }
  }

However, your code does not need to be that generic. If you already know which view may be interested to be notified, you can use

IViewPart part = page.findView(viewId):

to retrieve the interested IViewPart and after checking that it will respond to ISetSelectionTarget (either by implementation or adaptation), you can send it a selectReveal() message directly.

However, the default Welcome page I had on my Ubuntu desktop is quite broken

• it is ugly
• the links to the workbench are broken (links like http://org.eclipse.ui.intro/showPage?id=overview open in Firefox)
• when I close it, it asks me to save a file

After a little search on eclipe.org SWT FAQ, it appears that by default, Ubuntu is missing the MOZILLA_FIVE_HOME which is required by SWT to use the web browser internally.

I just added this variable before starting Eclipse:

export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox/

and the Welcome page appeared as expected:

I really like the new theme (Circles) by the way. )

It is quite simple but I stumble upon it before finding how in Eclipse you can stop the traversal of SWT Control from a TraverseListener implementation.

In your listener, handle the TraverseEvent event and then just

event.doit = false;

and the system will stop traversing the Controls.

Everything is well explained in TraverseEvent javadoc (but I’m guilty of not reading javadoc until I need it…). The explanation is worth a read and shows how powerful traversal can be in eclipse using both TraverseEvent detail and doit fields.

The Apache Way

• Communities first, code second
• Communities over individuals
• Apache central to Open Source work but Eclipse is also gravitating to the center
• The license trend is going to the bottom

 Proprietary
  |
  v
 Restricted
  |
  v
 Copyleft (GPL, EPL)
  |
  v
 Non-copyleft (APL, BSD)   

I found it quite interesting to see how Apache is organized and how Eclipse compares to it.

For now, there is few overlaps between Apache and Eclipse communities but it has already started.
For example, both communities now offer an OSGi implementation:

• Equinox for Eclipse
• Felix for Apache (in the incubator)

It it going to be interesting to see where things are going…

Scripting Eclipse means a lot of different things to different people.
My own interest is to provide scripting ability to a RCP application so that its users can customize it for their needs and create their own workflow.

For example, imagine that the RCP application is used to manage remote resources. Each resources can be manage individually through a set of methods.
But what if you want to provide a workflow for advanced operations?

One way to do this is through wizards. But with that solution, users lose control like Joel Spolksy explained in his presentation.
Besides it is very difficult to provide wizards which makes simple things simple and complex things possible. They tend to become uncluttered and undecipherable.

Another way is to provide cheatsheets. However, interaction between the cheatsheets and the user interface remains basic. And users are still not in control: they must follow the steps dictated by the cheatsheets.

Now, imagine that we expose a DOM of the managed resources and we let users script their processes. They are in control and they manage the workflow of their resources. They win because they are in control and we (the RCP developpers) win because we can keep our RCP application simple. We just have to expose the simplest useful DOMs to our users to let them handle themselves their more complex and specific processes.

I have not yet created an update site for it so you have do download it and install it in your plugins directory manually.
It provides a out variable that you can use to write to a console.

Here is the mandatory “Hello, World” example:

--- Came wiffling through the eclipsey wood ---
/*
 * Menu: Console > Hello
 * Kudos: Jeff Mesnil
 * License: EPL 1.0
 * DOM: http://jmesnil.net/eclipse/updates/net.jmesnil.doms 
 */

function main() {
  out.print("Hello, ").println("World");
 }

--- And burbled as it ran! ---

and its output