The diagram Figure 46.2, “Class diagram” describes relationships between Java classes:

Figure 46.2. Class diagram

When IC2D is used to monitor a host, it looks for any available runtimes on the host, then enumerates any nodes, virtual nodes and active objects contained within each runtime.

In order to do this, it grabs the URL entered by the user, then creates a new HostObject and add it to the WorldObject. Next, a thread starts and regularly queries the WorldObject to explore itself. The following sequence diagram explains how a WorldObject explores itself for the first time (Figure 46.3, “The world exploring itself for the first time”).

Figure 46.3. The world exploring itself for the first time

Now all objects are found. And these operation will be regularly repeated until the user stops monitoring.

The Graphical Editing Framework (GEF) allows developers to take an existing application model and quickly create a rich graphical interface.

GEF employs an MVC (Model View Controller) architecture which enables simple changes to be applied to the model from the view.

This section introduces the needed to the comprehension of GEF. For more details about GEF go to the Section 46.1.1.4, “Links” .

We describe here the implementation of the MVC pattern used within IC2D:

Figure 46.4. The Models

Figure 46.5. The Controllers and the factory

Figure 46.6. The Views

Three things to not forget

In blue, the data which we use with GEF. As you can see it, they are organized in a tree structure.

Figure 46.7.  The data strucure of the monitoring plugin

Description of the creation of the controllers and the figures step by step :

The official site of GEF: http://www.eclipse.org/gef/

A web page referring a lot of very interesting links about GEF: http://eclipsewiki.editme.com/GEF

A detailed description of GEF : http://eclipse-wiki.info/GEFDescription

A tutorial : 'Building a GEF-based Eclipse editor' : Part 0 , Part 1 , Part 2 , Part 3 .

Somes GEF examples : http://eclipse-wiki.info/GEFExamples

The pattern Observer/Observable is used to update the figures when the model changes.

In the Figure 46.8, “Observable objects” you can see all the observable objects with methods which can call notifyObservers .

Figure 46.8. Observable objects

In the Figure 46.9, “Observer objects” , you can see all the observer objects and where the method update is overriden.

Figure 46.9. Observer objects

In the Table 46.1, “Observable and Observer objects” , you can see each observable with their observers.

In the following diagram, you can see all classes necessary to the espionage of the active objects.

Figure 46.10. Spy classes

When a node is found for the first time, IC2D put a spy in the node.

Once the spy is in the node, it regularly asks to the SpyEventManager to provide all the events. The next step is explained in the Figure 46.11, “Active Objects' events management”.

Figure 46.11. Active Objects' events management

A new spy is created each time that a new Node is found.

The NodeObject calls its "addSpy()" method :

In some cases, you may want to hide some objects to the users, i.e. don't monitor some internal objects. For example, spy objects used by IC2D for monitoring JVMs. That's why we introduce the concept of filtering in the monitoring plugin.

The package org.objectweb.proactive.monitoring.filters contains:

If you want to create a plug-in for IC2D, you have to use the Eclipse's Plug-in Development Environment (PDE) . This is a complete environment that Eclipse provides for plug-in development. The PDE adds a new perspective and several views and wizards that help you create, maintain, and publish plug-ins. The PDE creates boilerplate starter code that you can use to build your plug-in. This section explains how to use the plug-in project wizard to create your plug-in.

Figure 46.14. Create a new project

Figure 46.15. Specify name and plug-in structure

Figure 46.16. Specify plug-in content

The plug-in project has the file structure illustrated in the followed figure.

Figure 46.17. The plug-in structure

The plug-in manifest ties all the code and resources together. When you first create a plug-in, Eclipse will create and open the manifest for you automatically. The manifest is split into two files: MANIFEST.MF and plugin.xml . PDE provides a fancy editor to modify the options stored in these files (see Figure 46.18, “ Interface for editing the manifest and related files. ” ) but also allows you to edit the source directly.

Figure 46.18.  Interface for editing the manifest and related files.

MANIFEST.MF

The OSGi bundle manifest is stored in MANIFEST.MF. OSGi is the name of a standard that Eclipse uses for dynamically loading plug-ins. Example 46.1, “MANIFEST.MF” shows the OSGi bundle manifest generated by the plug-in wizard. Everything in this file can be edited by the Manifest editor, so there should be no need to edit it by hand . However if you need to, just double-click it in the Package Explorer to bring up the Manifest editor, then click on the MANIFEST.MF tab in the editor to see and modify the source.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2 Bundle-Name:
Example Plug-in Bundle-SymbolicName:
org.objectweb.proactive.ic2d.example
Bundle-Version: 1.0.0 Bundle-Activator:
org.objectweb.proactive.ic2d.example.ExamplePlugin
Bundle-Localization: plugin Require-Bundle:
org.eclipse.ui, org.eclipse.core.runtime
Eclipse-AutoStart: true
						

plugin.xml

The Eclipse extension manifest is called plugin.xml. It's used for defining and using Eclipse extension points , so if you're not using extension points then this file may be omitted. Extension points are the fundamental way that Eclipse plug-ins are tied together. This new plug-in is not yet using extension points so the plug-in wizard didn't generate the plugin.xml file.

The plug-in class is an optional singleton class that can be used to store global information for the plug-in. It's also a convenient place to put a few static utility functions used by other classes in the plug-in. See the listing Example 46.2, “ExamplePlugin.java” for the plug-in class that was created for us by the plug-in wizard.

package org.objectweb.proactive.ic2d.example;

import org.eclipse.ui.plugin.*;
import org.eclipse.jface.resource.ImageDescriptor;
import org.osgi.framework.BundleContext;

/**
 * The main plugin class to be used in the desktop.
 */
public class ExamplePlugin extends AbstractUIPlugin {

	//The shared instance.
	private static ExamplePlugin plugin;
	
	/**
	 * The constructor.
	 */
	public ExamplePlugin() {
		plugin = this;
	}

	/**
	 * This method is called upon plug-in activation
	 */
	public void start(BundleContext context) throws Exception {
		super.start(context);
	}

	/**
	 * This method is called when the plug-in is stopped
	 */
	public void stop(BundleContext context) throws Exception {
		super.stop(context);
		plugin = null;
	}

	/**
	 * Returns the shared instance.
	 */
	public static ExamplePlugin getDefault() {
		return plugin;
	}

	/**
	 * Returns an image descriptor for the image file at the given
	 * plug-in relative path.
	 *
	 * @param path the path
	 * @return the image descriptor
	 */
	public static ImageDescriptor getImageDescriptor(String path) {
		return AbstractUIPlugin.imageDescriptorFromPlugin("org.objectweb.proactive.ic2d.example", path);
	}
}
					

The build.properties file (see Example 46.3, “build.properties” ) will be needed when exporting the application for others to use . In particular if your application needs any resources like icons they should be listed here in the bin.includes section. The Plug-in Manifest editor provides a convenient interface to modify this file that is less error-prone than modifying it by hand.

source.. = src/
output.. = bin/
bin.includes = META-INF/,\ .
					

In the project org.objectweb.proactive.ic2d , open ic2d.product . In the Configuration tab, click Add .

Figure 46.19. Configuration

Then select your plug-in.

Figure 46.20. Plug-in selection

Figure 46.21. About product Plug-ins

Perspectives provide an additional layer of organization inside the workbench page. A perspective defines an appropriate collection of views , their layout, and applicable actions for a given user task. Users can switch between perspectives as they move across tasks. From an implementation point of view, the user's active perspective controls which views are shown on the workbench page and their positions and sizes. Editors are not affected by a change in perspective.

A new perspective is added to the workbench using a simple two step process :

Step 1 : Add a Perspective Extension to the plugin.xml file

Figure 46.23. Extensions tab (no extensions)

Ajouter un screenshot

Figure 46.24.  Extensions tab (org.eclipse.ui.perspectives)

Figure 46.25. Extensions tab (Example)

If the plugin.xml file didn't exist, it is now created. Example 46.4, “plugin.xml” shows the plugin.xml file that was created.

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
   <extension
         point="org.eclipse.ui.perspectives">
      <perspective
            class="org.objectweb.proactive.ic2d.example.ExamplePerspective"
            id="org.objectweb.proactive.ic2d.example.ExamplePerspective"
            name="Example"/>
   </extension>
</plugin>
          

Step 2 : Define a Perspective Class for the Extension within the Plug-in

Now we need to define the perspective class which must implements the IPerspectiveFactory interface :

package org.objectweb.proactive.ic2d.example;

import org.eclipse.ui.IPageLayout;
import org.eclipse.ui.IPerspectiveFactory;

public class ExamplePerspective implements IPerspectiveFactory {

	public static final String ID="org.objectweb.proactive.ic2d.example.ExamplePerspective";
	
	public void createInitialLayout(IPageLayout layout) {
		// TODO Auto-generated method stub

	}

}
					

You have created your first perspective !

A view is typically used to navigate a hierarchy of information, open an editor, or display properties for the active editor.

Create a view looks like create a perspective. You have to add a perspective extension to the plugin.xml file and to define a view class for the extension within the plug-in .

Step 1 : Add a View Extension to the plugin.xml file

Add an extension : org.eclipse.ui.views, then add a view and configure it.

An editor is a visual component within a workbench page. It is used to interact with the primary focus of attention, which may be a document, data object, or person. The primary focus of attention is a reflection of the primary task.