4. Plug-Ins & Storage

4.1. Plug-ins & Server Files

All RapidContext server functionality is provided by plug-ins. The plug-in ZIP files are stored in the plugin/ directory on the server. The figure below illustrates the directory structure:

As seen above, most plug-ins are stored as packed ZIP files in the plugin/ directory. Only the local plug-in is stored in unpacked form by default. There are two special plug-ins that cannot be removed or unloaded:

The list of plug-ins to load on startup is stored in the config.properties file (in the plugin/local/ directory). The plug-in order in that file also controls the order in which plug-ins are loaded.

4.2. Storage Overview

The plug-ins are managed by the RapidContext storage subsystem. The server storage provides a unified view of all objects in the system, similar to a virtual file system. It has a number of important features:

4.3. Storage Tree

The storage tree can be browsed and inspected directly (requires admin role) from the rapidcontext/storage/ path on the server. The directory tree is structured into directories based on the object types, as seen below:

app/ App configuration files
connection/ Connection configuration files
environment/ Environment configuration files
files/ Contains files to serve via HTTP (maps directly to URL:s)
lib/ Java JAR libraries to load (server-side)
plugin/ Currently loaded plug-ins
procedure/ Procedure configuration files
role/ Role configuration files
session/ Currently active sessions
storage/ Mount-points for storage providers (plug-ins, etc)
type/ Storage type configuration files
user/ User configuration files

All plug-ins are mounted to the storage tree, under the storage/ directory. Active (loaded) plug-ins are also overlaid onto the root storage tree. Each plug-in therefore shares some parts of the overall directory layout (outlined above). The plug-in storages may also “shadow” objects in the tree from other plug-ins, which is used when modifying objects.

The built-in storage mount points are structured as shown in the figure below:

4.4. Storage Data Types

The objects retrieved from storage all have a storage data type. The data types can be divided into three categories that cover everything:

The first two categories of objects expose their storage data type in the type property, e.g. connection/jdbc for a JDBC connection object. The data types themselves are also objects that can be retrieved from the type/[type identifier] storage path. The example below shows parts of the JDBC connection data type:

# General properties
id = connection/jdbc
type = type
description = The JDBC connection type. JDBC connections allows execution of \
    SQL queries and statements to any JDBC data source. Connections may be \
    pooled for maximum resource utilization.
initializer = org.rapidcontext.app.plugin.jdbc.JdbcConnection

# Property array
property.0.name = url
property.0.description = ...
property.0.required = true

The object type initializer property links a data object to a Java object. Whenever such an object is retrieved from storage, the corresponding Java object will be automatically created and put into the storage cache. The Java objects in the storage cache may remain there indefinitely, but roughly every 30 seconds a cache cleanup job will destroy any objects reporting an inactive status.