The Monitoring plugin provides the Monitoring perspective displayed in the Figure 2.1, “The Monitoring Perspective”.

This perspective defines the following set of views :

Figure 2.1. The Monitoring Perspective

In order to monitor a new host:

Figure 2.2. Monitor New Host Dialog

The Monitoring view provides some functionalities which are accessible through a set of buttons. This section describes all these buttons:

Figure 2.3. Monitor a new host

Display the "Monitor a new host" dialog in order to monitor a new host.

Figure 2.4. Set depth control

Display the "Set Depth Control" dialog in order to change the depth variable. Let us assume we have 3 hosts (A, B and C). On A, there is an active object oaA which communicates with another active object oaB which is on B. This one communicates with an active object oaC on C, and aoA does not communicate with aoC. Then if we monitor A, and if the depth is 1, we will not see aoC.

Figure 2.5. Set time to refresh

Display the "Set Time to Refresh" dialog in order to change the time to refresh the model. And find the new added objects.

Figure 2.6. Refresh

Refreh the model.

Figure 2.7. Enable/Disable Monitoring

When the eye is opened the monitoring is activated.

Figure 2.8. Zoom In

Figure 2.9. Zoom out

Figure 2.10. New Monitoring View

Open a new Monitoring view. This button can be used in any perspective. The new created view will be named 'Monitoring#number_of_this_view'

All the other buttons concern the IC2D debugging features and will be describe latter on in Chapter 3, Using IC2D debugging features.

On the top of the Monitoring View, one can find the Virtual Nodes list. When some nodes are monirored, their virtual nodes are added to this list. And when a virtual node is checked, all its nodes are highlighted.

Figure 2.11. Virtual nodes List

At the bottom of the Monitoring view, one can find a set of buttons used to manage the communications display:

The main view, shown in Figure 2.13, “ Time snapshots for 2 active objects ”, is composed of bar charts (one chart per active object). Each chart represents cumulated times of different states that the active object has been in.

Figure 2.13.  Time snapshots for 2 active objects

The tree view, shown in Figure 2.14, “ Hierarchical decomposition of the total time of an active object ”, allows a more detailed hierarchical decomposition view of the total time for a particular active object.

Suppose that your active object class is:

package org.objectweb.user.example;

public class ActiveObjectClass{
    public ActiveObjectClass(){}

    public void methodA(Integer i, Double d){}

    private void methodB(){}

    protected void methodC(){}
}

The hierarchical time decomposition includes times of user active object class methods (that must be public and non-final) served as requests (i.e. called by other active objects).

Figure 2.14.  Hierarchical decomposition of the total time of an active object

The timeline view shown in Figure 2.15, “ The timeline for 7 active objects ” represents all events that were recorded during a certain time-lapse. The color of each event corresponds to the same color defined in the Legend view. This view shows the intensity of particular states (serving, waiting for request, etc.).

Figure 2.15.  The timeline for 7 active objects

The standard breakpoints are located inside the service thread of an active object. These breakpoints do not block the other threads (like immediate services, JMX, ...). There are 3 points:

The immediate service breakpoints are located inside each immediate service thread. The functionalities of these breakpoints are the same than those of standard breakpoints. For one object, there may be several immediate services blocked at the same time. There are 2 points for this specific service:

The main functionality of the step by step mode is to stop and restart an active object (enable/disable button). This functionality is available for one object or for each object in a node, a JVM, a host or a world (all object visible on IC2D monitoring). If an active object has been stopped, it is possible to restart it up to the next enabled breakpoint (next step button).

Figure 3.9. Pause

The filter tool allows to enable or disable some specific breakpoints. For example, it is possible to enable a new service and send request breakpoints, and disable the others.

Figure 3.10. filters

Figure 3.11. Popup filters

This tool enables to introduce a delay after the breakpoints. Using this tool, the active object will stop at each breakpoint and will automatically restart after the delay.

Figure 3.12. slow motion

This view displays some informations of an active object when it is selected. From this view, one can restart a previously blocked active object.

This tool also enables to choose the blocked service to restart (immediate or not).

Figure 3.13. Information

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

Figure 5.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 5.3, “The world exploring itself for the first time”).

Figure 5.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 5.1.1.4, “Links” .

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

Figure 5.4. The Models

Figure 5.5. The Controllers and the factory

Figure 5.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 5.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

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 5.8, “Observable objects” you can see all the observable objects with methods which can call notifyObservers .

Figure 5.8. Observable objects

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

Figure 5.9. Observer objects

In the Table 5.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 5.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 5.11, “Active Objects' events management”.

Figure 5.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 5.14. Create a new project

Figure 5.15. Specify name and plug-in structure

Figure 5.16. Specify plug-in content

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

Figure 5.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 5.18, “ Interface for editing the manifest and related files. ” ) but also allows you to edit the source directly.

Figure 5.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 5.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 5.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 5.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 5.19. Configuration

Then select your plug-in.

Figure 5.20. Plug-in selection

Figure 5.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 5.23. Extensions tab (no extensions)

Ajouter un screenshot

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

Figure 5.25. Extensions tab (Example)

If the plugin.xml file didn't exist, it is now created. Example 5.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.

In Eclipse, go to: 'Help'>'About Eclipse SDK'>'Feature Details' And search 'Graphical Editing Framework' as Feature Name.

In Eclipse, go to:

See http://subclipse.tigris.org/install.html

See http://proactive.inria.fr/svn_access.htm

Maybe, the plug-in try to export some classes which it doesn't contains. So, on the 'org.objectweb.proactive.ic2d.lib' project, do a right click, and select 'Properties' Go to Java Build Path, and select the 'Libraries' frame. Now remove jar files which displays an error message.

Install the RCP delta pack. See Export Product