Plugin Management

In addition to the structural classloader information - the plugin file may contain the declaration of a main class or an internal resource and namespace. The resource path information is a special case used within the Depot build system to support dynamic task loading. The main class declaration is the entry point for classic plugin class loading relative to an established classloader.

The Transit repository service provides support for class creation and object instantiation. Class creation is typically used by applications that handle a particular semantics concerning a plugin model whereas the Transit object instantiation provides a simple but flexible model suitable for control over selectable sub-system strategies (e.g. the loading of a logging system or application runtime).

The following code fragments demonstrates the creation of a plugin instance using Transit's standard plugin loader.

We create a API project called hello-api, which contains the following interface.

/**
 * API of the Hello service.
 */
public interface Hello
{
    void announce();
}

And then we need an implementation of the API, and we call that hello-impl.

/**
 * Implementation of the Hello API.
 */
public class HelloImpl
    implements Hello
{
    private String m_message;

    public Hello( String message )
    {
        m_message = message;
    }

    public void announce()
    {
        System.out.println( m_message );
    }
}

so we need to do the following from the class that loads the plugin;

  URI uri = new URI( "artifact:part:mycompany/thisproject/hello-impl#1.4.1" );
  Object[] args = new Object[] { "Hello, World!" };
  Part part = Part.load( uri );
  Hello plugin = (Hello) part.instantiate( args );
  plugin.announce();

For this to work, you will need to create the plugin meta descriptor. The easiest way is to use the DPML Depot build system, but it can also be done manually or with other tools. The above would need a simple descriptor like this;

<?xml version="1.0"?>

<part xmlns="dpml:part"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <info title="Example">
    <description>An example plugin.</description>
  </info>

  <plugin class="HelloImpl">

  <classpath>
    <public>
      <uri>artifact:jar:mycompany/thisproject/hello-api#1.4.1</uri>
    </public>
    <private>
      <uri>artifact:jar:mycompany/thisproject/hello-impl#1.4.1</uri>
    </private>
  </classpath>

</part>

Now, the beauty of Transit is that IF the hello-api artifact is present in the parent classloader (or higher), the API classloader will NOT receive an additional instance of the Jar. This means that, if the plugin user have the hello-api already loaded it is not added to the API classloader, and the correct classloader management is ensured. Furthermore, if any of the Classloaders in the chain becomes empty, i.e. no new URLs not present in the parent structure, then the Classloader in question is not created.