PlugIns

The D1 kernel is relatively small and consists only of the services required for local messaging. All other content is provided via plug-ins.

The PlugIn system is kept simple. However, plug-ins can still participate fully in messaging.

Plug-in Interface

Plug-ins are JAR files and have a class that implements the IPlugIn interface. Here is an example of the class for the Monitor PlugIn:

package de.softdevel.d1.monitor.impl;

import java.net.URL;
import java.net.URLClassLoader;

import de.softdevel.d1.exception.CException;
import de.softdevel.d1.kernel.IKernel;
import de.softdevel.d1.plugin.IPlugIn;

public final class CModule implements IPlugIn
{
    private CMonitorFrame mFrame = null;

    @Override
    public void startPlugin(final URL aUrl,
                            final URLClassLoader aClassLoader,
                            final IKernel aKernel) throws CException
    {
        if (mFrame == null)
        {
            mFrame = new CMonitorFrame(aKernel);
        }
    }

}

The class is very simple. As you can see, only the kernel is needed to bind the monitor to the messaging. Only a swing frame is created here, which accepts the kernel for the use of the messaging.

This simplicity is also the reason why we simply run programs using devel. one as a plug-in. PlugIns can easily be copied from one NODE to another. It is also easy to implement GUI programs as a plug-in. It is also easy to split the implementation of the user interface between different plug-ins.

Plug-in Manifest

In order for the kernel to find the correct plug-in class, it must be specified in the JAR manifest. Technically, this works with many build systems. We use Gradle:

apply plugin: 'java'
apply plugin: 'checkstyle'

version = '1.0'

repositories {
    jcenter()
}

dependencies {
    compile project(':D1Kernel')
    compile project(':D1MonitorAPIPlugIn')

    compile 'org.slf4j:slf4j-api:1.7.21'

    testCompile 'junit:junit:4.12'
}

jar {
    manifest {
        attributes(["Manifest-Version": "1.0"])
        attributes(["Implementation-Title": "D1 Monitor PlugIn"])
        attributes(["Implementation-Vendor": "softdevel GmbH, Hohenwestedt, Germany"])
        attributes(["Implementation-URL": "www.softdevel.de"])
        attributes(["Implementation-Version": version])
        attributes(["PlugIn-Class": "de.softdevel.d1.monitor.impl.CModule"], "devel.one")
    }
}

The last line of the manifest entry is important (PlugIn-Class). The complete class name is entered here.

Loading Sequence

A plug-in may depend on other plug-ins. The order of loading is defined in the file plugins. txt in the configuration directory:

D1NetworkPlugIn
D1TcpPlugIn
D1LogCatcherPlugIn
D1MonitorAPIPlugIn
D1MonitorPlugIn
D1MonitorLogPlugIn
D1MonitorSequencePlugIn
D1TestPlugIn
D1GateKeeperPlugIn
D1Application
D1PrivateOnlineTestPlugIn

Since the plug-in D1MonitorPlugIn depends on the plug-in D1MonitorAPIPlugIn, the latter is loaded first.

The above plug-in control file is also useful for other reasons. All plug-ins of your systems can be located centrally in a directory on a file server. Only those plug-ins are loaded that are also entered in the control file. This makes it easier to work with system updates of many D1-NODES.