Modules, whether packed in a JAR file or expanded directories in the host filesystem, contain
a hierarchical set of resources. It is these resources that form the static definition of a module.
Module Resources - ffcpl: scheme
The ffcpl: URI scheme is a scheme for addressing the virtual URI address space of a module.
Requests for resources using the ffcpl: scheme are resolved against the internal address space of the module, which is defined according to
the mapping section in the module definition (see the Module Development Guide). Mapping entries
defined with <this> indicate that resources should be looked for in the current module's local directory structure.
ffcpl: stands for File First ClassPath Later.
ffcpl: resource management is a two-layered filesystem. A first layer is the scratch filesystem, a
real directory located below [install]/scratch/.
The second layer is the module filesystem, which is based on the Java classloader mechanism. ffcpl: first tries to find a resource in
scratch and falls back to the module's classpath if it doesn't discover it.
The figure below shows a source, sink and re-source using the ffcpl: scheme - for this illustration we will assume the resource
is in the same module as the request was issued and will not discuss the Module Manager's resource resolution process.
SOURCE: A request is made for a resource using URI ffcpl:/resource.xml. The resource is sought in the scratch directory, it
is not found so the module is checked. The resource is found in the module and returned.
SINK: Another request is made to write a new resource to URI ffcpl:/resource.xml. The new
resource value is written to the scratch filesytem. By default scratch is a real directory located at [install]/scratch/.
The resource is therefore written to the file [install]/scratch/resource.xml. Module resources are never directly overwritten
they are only overridden.
SOURCE: Another request is made for ffcpl:/resource.xml. The resource is found in scratch and returned.
Requests to delete an ffcpl: resource will cause the resource to revert to it's base state- i.e. if there is an entry in
the scratch directory it will be deleted.
An ffcpl: resource can be read from an external module if the resource is exposed on the public interface of the
owning module. However only the owning module is able to update (direct sink or delete requests at) the resource- an exception is
thrown otherwise. If a module wishes to expose mutable resources on its interface it should provide a specific service interface to
do so.
ffcpl: is very useful as it allows default module resources to be overridden by local copies and so allows modules to hold state.
ffcpl: as REST interface
In the context of a local resource within a module ffcpl: is analogous to the file: scheme. However, more broadly,
ffcpl: is the addressing scheme for the NetKernel URI address space - in this sense ffcpl:
is frequently used to provide REST-like service interfaces exposed on the public interface of a module.
When exposing services using ffcpl: on a module's public address space it is common to use ffcpl: as an Active URI and
supply named arguments which can be used by the internal implementing process.
Java ClassLoader
Each module within NetKernel has its own classloader which creates a context dependent classpath. A detailed guide is
provided here. As we have seen above, the context-dependent classpath is
the second tier of the ffcpl: resource scheme.
Dynamic Change Detection
Module resources, including all scripting language source code, located in an uncompressed directory are
monitored for changes by the kernel. The time period for the frequency of change detection can be
set here.