Modules can be dynamically added, updated or removed from a running NetKernel instance. Modules can be declared in three different ways depending up what type of module they are. These types are:
STEM modules provide the minimal functionality to boot NetKernel.
Within this minimal set of functionality the system further loads all the further required modules by the user and installed by Apposite.
This minimal set of functionality is called the init system and is started when the InitEndpoint in the
The STEM modules are defined in the file [install]/etc/stem-system.conf. Generally this file should not be user edited unless a specific non-repository patch is being applied. The STEM modules may be updated when needed by Apposite repository tool.
Apposite is NetKernel's distribution repository tool. It enables you to update, install and remove modules that are provided in one of the three repositories (main/universe/multiverse) for either NetKernel Standard Edition or NetKernel Enterprise Edition.
Apposite installed modules are declared in the file [install]/etc/modules.xml. Generally this file should not be user edited unless a specific non-repository patch is being applied. Care should be taken not to move or remove system modules as Apposite will update modules.xml every time it updates and restore this file to a consistent state. If you want to remove modules it is better to use the Apposite tool.
This file has the following structure:
Runlevel is an attribute given to module declarations. It is used to determine if modules should be commissioned
or not when NetKernel boots. Runlevels are a familiar concept in operating
systems. Usually modules are assigned by increasing integers from 0 based on how low level they are. Usually applications
sit at the highest runlevels. By changing the
netkernel.init.runlevel kernel property the maximum
runlevel that will be commissioned is defined.
Runlevels are further discussion in the Software Process Guide.
The directory [install]/etc/modules.d/ (this directory is configurable in kernel.properties) may contain additional XML files with a schema almost identical to /etc/modules.xml. These will be automatically detected and any modules they contain will be deployed. URLs contained in any files here will also be assumed relative to the install path of NetKernel.
Best practice is therefore to use the modules.d directory to manage your own modules.
If you add an attribute
@devmode="true" to your <modules> tag
then NetKernel will consider that any change to that file is an indication to
recommission the complete set of modules referenced by it.
The module wizard can be used to create new modules from boilerplate definitions customized with user supplied fields and configurable options.