Module Physical Structure
NetKernel modules may exist either in their own directory or a JAR file.
The only file required is the module definition file,
module.xml
,
which must be located at the top level of the module's structure.
The module definition file is described in the discussion about the module
logical structure.
The physical structure of a module is left for the
developer to define.
Best Practices
Standardizing the location of various module parts will make long-term
maintenance easier.
For example:
module.xml - module definition file
etc/ - configuration files
resource/ - various resources such as image files and script code
com/ - the highest level directory for a Java package (such as com.mycompany)
Libraries
If you are developing a library - or any module that is called from a higher
level application layer - you need to consider if your module's services
will be accessing resources in the address space of the calling module.
(Please see the detailed explanation of how modules can access other modules
in the request context using the superstack).
Always be aware that when you make a request for a resource, the
module's local address space will be searched first. Local resources, if they are present and
have the same URI, will mask resources higher in the superstack.
To avoid masking effects, we recommend that libraries should place local resources in
a directory structure using the Java package convention. eg /org/ten60/mylibrary/scripts/...
NetKernel Physical Structure
NetKernel is installed into a directory referred to as
[install].
Underneath this directory sub-directories hold NetKernel components.
NetKernel's module manager uses three pieces of information
about each module
to support dynamic module loading, unloading and updating:
-
Physical location: The physical location of the directory or
JAR file for each installed module is listed in the file
[install]/etc/deployedModules.xml
.
-
URI: A unique identifier for each module,
contained in the module's
module.xml
file.
-
Version: A version number for the module
contained in the module's
module.xml
file.
Physical Location
The physical location for each module
is listed as an
entry in deployedModules.xml
.
The physical location reference may be either
an absolute file: URI reference
or a location relative to the [install]
directory.
By custom, modules that use a relative location are
placed in the directory [install]/modules/
.
The following is an elided example
of deployedModules.xml
.
<modules>
<!---->
<module>modules/mod-fulcrum-frontend/</module>
<!---->
<module>modules/cache-standard-1.2.0.jar</module>
<!---->
<module>file:/home/randy/eclipse-workspace/NewModule/</module>
</modules>
Name and Version
Each module is defined in the module definition file, module.xml
.
Within module.xml
, the module's
identifying information is contained in the
identity
element
which contains the uri
and version
elements.
The uri
element must contain a unique
identifier for the module.
While this must be unique within a running installation
of NetKernel, we recommend using a globally unique
identifier based on a reverse DNS naming scheme.
Most modules in 1060 NetKernel start with "org.ten60.netkernel".
For example,
the front-end fulcrum module in the 3.0 release of NetKernel
has the following information:
<identity>
<uri>urn:org:ten60:netkernel:fulcrum:frontend</uri>
<version>2.1.6</version>
</identity>
The
version
element contains the current version of the module.
Version numbers are significant as NetKernel can simultaneously
run different versions of the same module.
This capability allows NetKernel to manage smooth upgrading of systems
running in a 24 x 7 environment.