WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

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:

  1. STEM - The NetKernel bootloader loads a minimal set of modules which are then used to further initialise the system. The file [install]/etc/stem-system.conf declares these modules.
  2. APPOSITE - NetKernel's repository manager handles core distribution and library modules. It stores its module declarations in the file [install]/etc/modules.xml.
  3. MODULES.D - User created modules are declared in the [install]/etc/modules.d/ directory.

STEM Modules

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 urn:org:netkernel:ext:system is commissioned.

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:

  <module runlevel="2">modules/urn.org.netkernel.xml.core-2.3.1.jar</module>
  <module runlevel="7">modules/urn.com.mycom.myproj/</module> .........
where each module tag specifies the URL (which may be relative to the install path of NetKernel) of a module to load. This example shows the registration of a .jar module and an expanded module.


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.

@devmode Attribute

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.

<modules devmode="true">
  <module>...file:/ uri of the module to load...</module> ... as many modules as you like...

The module wizard can be used to create new modules from boilerplate definitions customized with user supplied fields and configurable options.