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.
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:
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:
The objects retrieved from storage all have a storage data type. The data types can be divided into three categories that cover everything:
.in the storage path.
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 (in YAML format):
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: - name: url description: |- The JDBC connection URL. (...) 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.
Sensitive data such as passwords or access tokens can be stored in a
hidden property which is prefixed by a .
character. Such properties are filtered out whenever an object is returned via
a procedure or similar. They remain available for Java implementations of
connections, procedures, etc.
The example below shows how the password property is hidden for user objects by default:
id: johndoe type: user name: John Doe description: A simple example user enabled: true realm: RapidContext .password: secret
Some properties are calculated or transient and should not be written to
storage. These computed properties are prefixed by a
_
character. Any operation that writes to storage will
filter these out.