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.