TechJava» TechJava – Articles tagged by plugin

Packaging Eclipse-based RCP for the use in enterprise context

Simon Zambrovski — Wed, 08 Jul 2009 20:00:33 +0000

Abstract

Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

Domain-specific component framework
Methods for master data management
Infrastructure services: authentication, authorization, communication, security, printing, reporting
Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.

The required plug-ins

Following the general idea of RCP packaging (see rules provided in the RCP Book) and assuming one target platform (in terms of one RCP product), one top-level plug-in and should be defined. In addition, we assume at least one in-house framework plug-in and at least one application-specific plug-in. Usually there will be more of each type, but it will not change the picture much. Important at this point is the fact, that the application-specific code depends on the in-house framework code. In order to simplify the identification of the plug-ins, an example project is introduced. Let’s assume the project is called FooBar. Then, the plug-ins are called:

de.techjava.foobar: This is the functional plug-in, which contains the application-specific code.
de.techjava.framework: This is the framework plug-in, which contains framework component code.
de.techjava.foobar.product.standalone: This is an application and product definition plug-in which contains the definition of the product and application-agnostic code for launching the application.

Managing plug-in dependencies

A difficult issue for the RCP beginners is the management of dependencies between plug-ins. Especially, the transition from the development of a single plug-in to the configuration of features and products seem to be non-trivial. In order to solve this problem, there are simple rules to follow. You can violate these rules in sophisticated scenarios, but for the beginners it is a good idea to follow them.

Create dependencies only if you need them. Each plug-in should only list plug-ins (or even better packages) it really depends on. Make sure to check it with the “Find unused dependencies” action available on the right-click in the Dependencies Tab of the Plug-in Manifest Editor.
Use versioning information. Plug-ins (or better bundles, or as Chris call them Plundles) provide version information. And it is highly advisable to include them in the import statements of the plug-ins, which simplifies the migration later on…
Don’t forget anything. Every Plug-in should appear in at least in one Plug-In section of the Feature definition. Every feature should be included by another feature, higher in the hierarchy.
Keep the hierarchy flat. For simple scenarios, it is sufficient to have two levels of features (top-level feature, one per-product and the underlying features include their plug-ins).
Don’t re-export dependencies. Every Feature for a group of plug-ins should also include plug-ins required by the members of the group. It does not hurt if a plug-in is included several times, but it does if it is not included at all. You can optimize here if you check which plug-ins are imported by the Eclipse RCP feature (which can be considered as stable), but it does not make assumptions about features developed by third parties.

Following these rules it is simple to create features for the corresponding plug-ins. Several plug-ins which belong together and are handled as a fixed piece can be grouped into Features. Usaging Features is highly advisable, and sometimes simply required (e.G. by RCP in a Java Web Start target deployment strategy). So in addition to the previously mentioned plug-in projects, at least three feature projects are required:

de.techjava.foobar.feature: This is a functional feature, which includes the de.techjava.foobar plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
de.techjava.framework.feature: This is a framework feature, which includes the de.techjava.framework plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
de.techjava.foobar.feature.standalone This is the top level feature, which is used for the product configuration. It includes the two features above and the Eclipse RCP feature (and optional other features used, like e.G. org.eclipse.help). It also includes exactly one plug-in, which is not included anywhere else: de.techjava.foobar.standalone.product

The product definition plug-in

The definition of the product is spread among several files. First of all the plug-in.xml of the de.techjava.foobar.standalone.product plug-in makes uses of two extensions:

org.eclipse.core.runtime.applications
org.eclipse.core.runtime.products

The application extension point is used to point to the Java class implementing the interface org.eclipse.equinox.app.IApplication. Along with this implementation, other classes needed to start up the RCP (like Advisors, etc…) are placed into the source directory of the plug-in. The product extension point is used for the association of the application with a product id. The previously-defined top-level feature includes all required features and the product definition plug-in. Finally, the .product file is the place, where all things are bound together: product id, application id, launcher parameters, and the one top level feature: de.techjava.foobar.feature.standalone. Other customization of the RCP is possible from the plugin-customization.ini, which is placed together with the .product file into the plug-in root directory.

As a result the following configuration should be achieved after the packaging is finished. The product references the product-id and the application, defined in the plugin.xml of the plug-in project it is contained in. The product configuration is feature-based and includes one top-level feature. The top-level feature includes all other features (functional, framework, Eclipse RCP, other optional) and the one plugin, in which the product file resides.

The simple example provided in this articles is available as sourcecode for download ( rcp-packaging.zip).

The framework hooks

In the introduced scenario, the packaging is not specific to the in-house framework. It just includes the feature containing the framework plug-in. This approach works fine, if the framework is used in a white-box manner, which means that the framework provides ready-to-use components to be plugged-in to the application (like e.G. a component for the master data management). The other type of frameworks is the so-called black-box framework, which provides components that have to be configured and integrated into the application components. In this case, the framework components can not be plugged-in using some declarative extension points, but need to be called from the application code. In the latter case, the dependencies appear between the plug-in launching the application (de.techjava.foobar.standalone.product) and the framework plug-ins. This requires a modification in the previous setup and the violation of one of the rules posted above. The plug-in has to define the dependency to the framework plug-in, but the top-level feature does not include the required plug-in directly, but imports the whole framework feature.

Technorati-Tags: eclipse, java, rcp, packaging, plugin, feature, product, enterprise systems

Eclipse Common Navigator Framework

Simon Zambrovski — Tue, 28 Apr 2009 01:13:02 +0000

Abstract

This article describes some efforts to use the Common Navigator Framework (CNF). In doing so it incorporates the information already covered in different articles, but also focuses on the specific use case of providing a view of something completely unrelated to the platform resources. So the aim is not to add some content to the “Project Explorer” which is an example of resource-oriented CNF usage, but to provide a view on a completely own data model.

Introduction

A very common UI element to represent data is a tree view. In SWT this UI element is implemented using the Tree widget. Following the MVC design pattern in the TreeViewer, JFace simplifies the usage of the Tree widget by delegating the task of content adoption to the ContentProvider and the label production to the LabelProvider (and using Sorters and Filters for sorting and filtering). Still for a single representation one has to construct a viewer and configure it with a corresponding Label- and ContentProvider. Further code reduction can be achieved by the use of WorkbenchContentProvider and WorkbenchLabelProvider if the elements can be made adaptable (implement IAdaptable interface and making them first-class workbench citizens). This approach is helpful, if the elements has to be displayed in several different viewers (e.G. Table). Finally, the Common Navigator Framework (CNF) is a facility provided by the Eclipse Platform which allows the usage of multiple Label- and ContentProvider on the same view. The providers are activated and used dynamically and can be configured declarative or programmatically. The advantage of CNF approach is the ability to combine elements in one view which have different origins(e.G. contributed by different plugins). CNF is used in Eclipse IDE: e.G. “ProjectExplorer” and “CVS Synchrnoize” are both instances of the CNF.

The usage of the CNF in your own application for purposes of representation of resource-based (and usually file-based) content is discussed in articles of Micael Elder in detail. The main idea is to instantiate the view, declare the default content and UI interface and make some additions where needed. This post has a different aim: we start from scratch and represent completely resource unrelated content. Before diving in the implementation details, some overview is provided.

UI Overview

There are many things which can be configured by the usage of CNF and it is beyond the scope of this post to cover all of them. Still there are several things to understand before the actual code can be written. The user interacts with a View which shows the data elements. Which elements are shown is configured using the navigation content extensions. Shown elements can be filtered with Filters and sorted using Sorters on behalf of the user. There are some predefined actions and their positions in the UI and corresponding extension points to contribute to. . The actions for Working sets, Customize View, Link with editor belong to this category. The user can also right-click on particular element in the tree and sees a popup-menu. This menu is configured based on the content element and can be (is) contributed by several plugins. The action contribution is also covered in the article series from Michael Elder.

Minimal non-resource based CNF viewer

The following example provide a set of minimal steps required to create a non-resource based CNF viewer. Your plug-in requires at least a dependency to org.eclipse.ui.navigator, org.eclipse.ui.

Data model

Let us assume a simple data model that should be represented in the view. There are two kinds of elements: parents and children (see Composite design pattern). Both Child and Parent are POJOs:

public class Child
{
    private String name;
    private Parent parent;

    public Child(String name)
    {
        super();
        this.name = name;
    }

    // getters and setter
...
}

Every child stores information about its parent, and every parent knows its children. In order to maintain the model in-sync the setChildren() method of the Parent class takes care of unsetting on all previous children and setting the parent on new children. This is just a sample code and there are different ways to implement this more elegantly (like e.G. holding the parent-child relation externally).

public class Parent extends Child
{
    private Child[] children = new Child[0];
    private Object rootElement;

    public Parent(String name)
    {
        super(name);
    }

    public void setChildren(Child[] children)
    {
        if (children != null)
        {
            setChildrensParent(null, this.children);
        }
        this.children = children;
        setChildrensParent(this, this.children);
    }

    /**
     * Sets children's parent
     * @param parent parent to be set
     * @param children children to set the parent
     */
    private static void setChildrensParent(Parent parent, Child[] children)
    {
        for (int i = 0; i < children.length; i++)
        {
            children[i].setParent(parent);
        }
    }

    // getter and setter
...
}

Please note, that nothing more is assumed about the parent and the child. It is a good idea to make such elements implement IAdaptable, which simplifies a lot of issues later, but this is another topic. You may have noticed the rootElement member of the Parent. Again, this is only used in order to keep the object tree structure as simple as possible and provide a hook to the root of the tree. The final tree structure contains one root object, several parent objects containing several child objects each.

public class Root extends PlatformObject
{
}

Declaring the viewer

In order to contribute a view to RCP/IDE the org.eclipse.ui.views extension point is used:

The two important things here are the class attribute pointing to the class of the CNF Navigator and the id attribute that will be used later in order to identify the view. Instead of pointing to the org.eclipse.ui.navigator.CommonNavigator
the reference to ParentChildNavigator is provided which is a subclass of the CommonNavigator. The reason for that is, that CommonNavigator gets its initial input (during initialization) from the Workbench by calling getSite().getPage().getInput(). In the IDE scenario, the default page input is IWorkspaceRoot, in the RCP scenario it is null and can be configured in the WorkbenchAdvisor. Instead, another implementation of getInitialInput() can be provided, passing the dummy Root object, which indicates the root of the tree.

public class CNFNavigator extends CommonNavigator
{
    protected IAdaptable getInitialInput()
    {
        return new Root();
    }
}

Defining viewer content

In order to see something in the freshly-defined viewer, the information about the content has to be provided. The extension point org.eclipse.ui.navigator.navigatorContent is defined for this purpose. The main element responsible for the content is called navigatorContent and contains the following information:

id – the id of the content, to be referenced in the viewer
name – the name of the content, which is seen in the Customize View dialog using the content tab, which can be activated or deactivated there by the user.
contentProvider – the contentProvider class responsible for providing content elements
labelProvider – the labelProvider class responsible for rendering a content element in the view

In addition, nested elements triggerPoints and possibleChildren describe when the current content is activated. This means that a CNF Viewer can compose the content coming from multiple providers and needs to know what content to display. These will be covered in the following sections.

How the platform uses the viewer

Before diving into the code section, it is worth spending a small section on the topic, how the platform uses the CNF viewer. In general, if an element is selected in the viewer, the CNF consults triggerPoints of all Navigation Content Extensions (NCEs) provided and tries to match the element to the trigger point expression. If the expression matches, the NCE is activated by the platform and the corresponding contentProvider is responsible for delivering content. If the element is activated by other means than in the viewer (e.G. in the Editor), the platform consults possibleChildren list and tries to match the corresponding expression. For resource-based approaches, the NCE with id org.eclipse.ui.navigator.resourceContent is usually provided. This NCE is enabled / triggered on any element that is instance of IResource. By this means e.G. the Project Explorer in the IDE passes the workspace root to the ResourceExtensionContentProvider which is responsible for delivering the children of the workspace root – the projects. In a non-resource based approach, the NCE must be triggered by the initial input of the viewer, in this example by the Root object. If the selected element is a Parent node, the NCE should also be triggered. The following definition of the trigger point accomplishes this task:

Since the children delivered by the content provider on Root as parent element are instances of Parent and on Parent as parent element are instances of Child, the possibleChildren code looks as follows:

Label and Content providers

After the way how the navigation content is being activated is discussed, the Content and Label providers can be addressed. The label provider implementation is straight-forward. Its task is to produce a textual and graphical representation of every element. In addition, it implements the IDescriptionProvider interface to provide description in the status bar when an element is selected. Please note, that this section is not CNF-specific but is related to JFace ContentProvider and JFace LabelProvider, as usual for any Viewer. It is provided here only for completion and if the user is not familiar with it in detail.

public class CNFLabelProvider extends LabelProvider implements ILabelProvider, IDescriptionProvider
{
    public String getText(Object element)
    {
        if (element instanceof Parent)
        {
            return ((Child)element).getName() + " [ " +((Parent)element).getChildren().length + " ]";
        } else if (element instanceof Child)
        {
            return ((Child)element).getName();
        }
        return null;
    }

    public String getDescription(Object element)
    {
        String text = getText(element);
        return "This is a description of " + text;
    }

    public Image getImage(Object element)
    {
        if (element instanceof Parent)
        {
            return PlatformUI.getWorkbench().getSharedImages()
              .getImage(ISharedImages.IMG_OBJ_FOLDER);
        } else if (element instanceof Child)
        {
            return PlatformUI.getWorkbench().getSharedImages()
              .getImage(ISharedImages.IMG_OBJ_FILE);
        }
        return null;
    }
}

The methods above are self-describing. For any element the text and image is selected based on element type. For children, the name is shown, for parents the number of children is displayed, additionally. The platform built-in icons of folder and file are used for convenience. The methods for the Label/Content provider usually follow this pattern of a instanceof cascade.

The content provider is responsible for the following tasks:

At requested of Root it should deliver the list of Parent elements
At requested of Parent it should deliver the list of its children (Child elements)
At requested of Child it should deliver an empty list

Since no real data model is available, its creation is hooked to the first access (that is, of course, for demonstration purposes only)

public class CNFContentProvider implements ITreeContentProvider
{

    private static final Object[] EMPTY_ARRAY = new Object[0];
    private Parent[] parents;

    public Object[] getChildren(Object parentElement)
    {
        if (parentElement instanceof Root)
        {
            if (parents == null)
            {
                initializeParents(parentElement);
            }
            return parents;
        } else if (parentElement instanceof Parent)
        {
            return ((Parent) parentElement).getChildren();
        } else if (parentElement instanceof Child)
        {
            return EMPTY_ARRAY;
        } else
        {
            return EMPTY_ARRAY;
        }
    }

    public Object getParent(Object element)
    {
        if (element instanceof Child)
        {
            return ((Child) element).getParent();
        } else if (element instanceof Parent)
        {
            return ((Parent) element).getRoot();
        }
        return null;
    }

    public boolean hasChildren(Object element)
    {
        return (element instanceof Root || element instanceof Parent);
    }

    public Object[] getElements(Object inputElement)
    {
        return getChildren(inputElement);
    }

    public void dispose()
    {
        this.parents = null;
    }

    public void inputChanged(Viewer viewer, Object oldInput, Object newInput)
    { /* ... */
    }
    ...
}

The class has three important methods: getChildren(Object), getParent(Object) and hasChildren(Object). The getChildren(Object) is responsible for delivering children elements to a given parent element. The getParent() delivers a parent for a given child element (e.G. when the child is selected using the editor and the viewer is requested to show the element in it). The hasChildren(Object) is a way of providing a more efficient implementation than (getChildren(element).length == 0). The getElements(Object) method is usually delegated to getChildren(Object). The difference between these methods is that getElements(Object) is called to obtain the tree viewer’s root elements, whereas getChildren(Object) is used to obtain the children of a given parent element in the tree (including a root). Since there is only one root (the not shown IWorkspaceRoot), it is OK to delegate. Finally, the parents member variable needs to be initialized on the first access, which can be done using the following code:

    /**
     * Init code for empty model
     */
    private void initializeParents(Object parentElement)
    {
        this.parents = new Parent[3];
        for (int i = 0; i < this.parents.length; i++)
        {
            this.parents[i] = new Parent("Parent " + i);
            this.parents[i].setRoot(parentElement);
            Child[] children = new Child[3];
            for (int j = 0; j < children.length; j++)
            {
                children[j] = new Child("Child " + i + j);
            }
            this.parents[i].setChildren(children);
        }
    }

Binding the content to the viewer

The last remaining piece in the puzzle is to bind the content defined in the navigation content extension to the view defined in the view extension. The extension point org.eclipse.ui.navigator.viewer is responsible for that. It consists of several parts: the viewer element, that references the id of the view and the viewerContentBinding element that one one hand specifies the view to bind the content to and on the other hand provides a reference to the content definition id.

Please note, that the content id is provided in the pattern attribute. Instead of pointing to particular content id, the regex can be used (e.G. de.techjava.rcp.cnf.content.*). That’s it, look at the result.

Under “Custimize View” the content tab allows to show the defined “virtual content”. Since no filters are defined, the filter section is empty.

Conclusion

To my opinion, for almost every application using a tree/list view to represent entities the CNF should serve as a basis for the implementation. Thus, CNF documentation should be improved and get to the level “for beginners” rather than “for experts”. In this post, I have tried to provide an introduction for non-expert RCP/PDE developers. I’m interested in your comments.

Further directions

Currently, neither filters, sorters nor actions or pop-up menu are defined for the viewer. This can be a subject of the follow-up post, if requested, but is partly covered in the articles of Michael Edler. Especially, the application of the new command framework has to be described.

Resources

Eclipse

Digital Paper Napkin by Michael D. Elder

A basic set of introduction articles written in 2006. The articles introduce contribution to the resource-based CNF viewer displaying the content of the property files. A good overview to get into the subject. The blog seems to be dead, according to many spam comments.

Eclipse from the bottom up by Michael Valenta

A good hint is to look on the implementation of the CVS Synchronize View. Pretty old content, but still valid.

vAAni by Aashish Patil

Weakly formatted article, providing some hints on how to implement a not “resource only”-based CNF viewer. Still, the information from here helped me to create a complete non-resource based CNF viewer described here.

Other

Thanks to Francis Upton, who reviewed the post and corrected some mistakes and misconceptions.

Special thanks to Michael “Mike” L. Baird for the beautiful picture of the compass. I found the picture on Google Image Search and became a big fan of his pictures (some of you know about my photo passion). It is funny that from all places in the world, the picture is shot in Morro Bay, about 200 Miles away from where I’m located now. It is also funny that Mike is a computer science guy, even if retired…

RCP with multiple application windows

Simon Zambrovski — Wed, 14 Jan 2009 21:25:37 +0000

Eclipse RCP by default promotes the usage of a single application window with multiple views and editors inside. This default can be changed to multi-windowed application. The platform API offers several methods to operate with multiple application windows:

package org.eclipse.ui;
...
public interface IWorkbench ...
{
/**
* Retrieves the number of opened windows
*/
public int getWorkbenchWindowCount();
/**
* Retrieves the array of opened windows
*/
public IWorkbenchWindow[] getWorkbenchWindows();
/**
* Openes a new window with given perspective
*/
public IWorkbenchWindow openWorkbenchWindow(String perspectiveId,
IAdaptable input) throws WorkbenchException;
/**
* Performs a perspective switch in a given window
*/
public IWorkbenchPage showPerspective(String perspectiveId,
IWorkbenchWindow window, IAdaptable input)
throws WorkbenchException;
...

}

Using this API, opening of new windows seems simple. For example one could define a perspective, that is always opens in a new window.

Closing windows is generally performed by calling close method on the IWorkbenchWindow instance.

package org.eclipse.ui;
...
public interface IWorkbenchWindow ...
{
  /**
   * Closes the window
   */
  public boolean close();
}

Unfortunaly, there is no elegant way to find out which window are you in. A workaround which uses Eclipse internal API works fine for WorkbenchWindow, which is a standard platform implementation of the IWorkbenchWindow interface.

/**
 * Determines if the window is a root window
 * @param window a window to be checked
 * @return true, if the window is considered to be a root window
 */
public static int getWindowId(IWorkbenchWindow window)
{
// HACK: note this could change in future
  if (window != null && window instanceof WorkbenchWindow))
  {
    return ((WorkbenchWindow)window).getNumber();
  }
  return -1;
}

The initial application window gets the id 1. The lookup in the implementation reveals that the internal method finds the smalles unused positive number and assigns it to the newly opened window. If you do not want to rely on this algorithm, just hash the newly created windows by they ids.

The PluginLoader – Applying Java Class loading Concepts

joker — Mon, 25 Feb 2008 08:29:16 +0000

Introduction

Many frameworks support plugins for increasing flexibility. They need to be loaded during runtime making it possible to change the supported features used in application without recompiling the framework and application themselves. Loading a plug-in means loading java classes, which is done by a class loader. We want to load the plug-ins from jar files, without providing a name for every JAR. Unfortunately, the java standard API does not contain a class loader for loading classes from a list of jar files in a directory. We need to provide it ourselves. In addition, the standard class loading mechanism is designed with following idea in mind: in runtime the application accesses the known classname, that is searched for in class path and loaded if found. In our case, we want to force the framework load it extensions, without setting up the class path before applications starts, which is a little different use case.

Simple JAR class loader

The first step is loading classes from jar files. For this purpose we create a class named JarFileClassLoader which should be able to load a class from a jar file. It inherits from ClassLoader, the Java default implementation for a class loader. Loading a class from a jar file means scanning each jar file entries, decide if it is a class then load it. Because we want to be flexible about the criterion we use to select our classes, we introduce an interface ICriterion, which decides for a given class if the criterion is fulfilled or not. Using this, the JarFileClassLoader can now scan a single jar file and load every class fulfilling the injected criterion. Loading a class means scanning the caches of the parent class loaders, calling the loadClass(String) method of the parents if not found and scanning the jar file afterwards if the class was still not found. This beahviour is described in a previous post, introducing the basics of Java Class Loading.

JarFileClassLoader is capable of loading a class if it does not reference other classes. These references have to be resolved during class loading time. Let consider the example of classes A and B where A references B. If A is loaded by a class loader CL, CL is asked for loading B also. This is done by calling the loadClass(String) method of CL. If B is contained in the jar file CL loads classes from, CL will find it and return it to the JVM. If B is not contained in CL’s jar file, CL’s parents are asked to load it. Thus the class will be loaded if it is contained in the classpath where one of the java class loaders will find it. If the class is contained in another jar file in the list, but not in the class path it will not be found and the loading will end with a ClassNotFoundException.

Plugin class loader

To tackle this problem we introduce another class, the PluginLoader. It contains a collection of JarFileClassLoaders and inherits from ClassLoader, thus is a ClassLoader itself. The PluginLoader acts as a parent for all JarFileClassLoaders and is therefore asked every time a class has to be loaded. It will then iterate over all JarFileClassLoaders calling the loadClass(String) method on all of them to find the class it looks for. This way, classes contained in sibling class loaders are found also without violating the rule that a class loader can only see classes of itself or its parents.

Putting everything together

Now the structure of our plug-in loader component becomes clear. What we additionally need to do, is get rid of all the stack overflows we produce with the above classes. The problem here is that any JarFileClassLoader asks its parent, the PluginLoader, to load a class. This will ask all child JarFileClassLoaders to load the class including the CL which asked the PluginLoader before. The result is an infinite call stack loop – a stack overflow. Therefore we relax the concept of the java class loading. We introduce a method loadClassSimple(String) on the JarFileClassLoaders which looks just in its very own jar file. If it does not find the wanted class it just throws an Exception without asking a parent or cache-lookups. This method is called by the PluginLoader only, therefore the rest of the class loading is not affected.

Last but not least we consider some performance issues. If a class is searched in other jar files, those have to be scanned every time again resulting in poor performance. Therefore we introduce a cache in the JarFileClassLoader containing every class that was loaded before. Every request is served now by trying to find the class in the cache first.

Limitations

Due to the fact, that PluginLoader asks its child JarClassLoaders to load a class in particuliar order, and the first class found will be taken, the order in which JarClassLoaders are asked matters. This issue can cause problems if e.G. different versions of the same library are deployed on location scanned by the PluginLoader and should be handled with care.

References

[2007,book] bibtex

G. Krueger and T. Stark, Handbuch der Java-Programmierung, , 2007.

@book{2007_KRUEGER, author = {Guido Krueger and Thomas Stark}, title = {Handbuch der Java-Programmierung}, month = Nov, year = {2007}, url = {http://www.javabuch.de/} publisher = {Addison-Wesley} isbn = {3-8273-2373-8} }
[,techreport] bibtex

"Java Class Loading: The Basics,".

@techreport{CL_BASICS author = {Brandon E. Taylor}, title = {Java Class Loading: The Basics}, url = {http://www.developer.com/java/other/article.php/2248831}