Limbus Engine - A multi classloader hot-deploy container
Table of Contents
Overview
The Limbus Engine is a hot-deployment runtime container that enables Java applications to load isolated classpaths at runtime. The Limbus Engine is an implementation of a plugin mechanism but even more: The Limbus Engine supports loading and unloading of a classpaths at runtime, sandboxing of the code in a way that loaded code cannot just do everything like System.exit();
, flexible routing of plugin output like logging or System.out
, a test library that can be used to (un)deploy classpaths in a JUnit tests and features like system monitoring, file-system abstraction and more.
The Limbus Engine uses the same hierarchy of classloaders like the most popular servlet container Apache Tomcat but enables the application to sandbox any code from a classpath. This way the plugin code can be restricted and the rest of the application remains isolated. The Java Security API is used to restrict the code running in a sandbox. A security manager keeps track of what a plugin is doing (read here for more information). The access to a plugin or from a plugin to it's host application is restricted by an interface designed by the host application.
The Limbus Engine provides a framework for developing host applications as well as plugin interfaces and implementations. This is useful for all applications that want to implement a plugin feature.
Modules
The Limbus Engine consists of many different components that are managed as Maven modules. This is an overview of the Limbus modules with a short description of what they are doing:
limbus-depchain-host
Dependency Chain for developing a host applicationlimbus-depchain-plugin
Dependency Chain for developing pluginslimbus-engine-api
Interfaces and structures for developing plugins as well as the Limbus Engine itselflimbus-engine-impl
Core-Module providing the Limbus Engine implementationlimbus-showcase-plugin
Demonstration of a plugin.limbus-showcase-launcher
Module for bootstrapping a Limbus Engine to demonstrate the (un)deploy feature usinglimbus-showcase-plugin
.limbus-event-multicaster
Core component for multicasting of method callslimbus-jsse
System component for initializing the Java Secure Socket Extensionlimbus-logging-api
Interface definitions for system components integrating logging frameworks.limbus-logging-jdk
System component integrating the Java Utils Logging Frameworklimbus-logging-log4j
System component integrating Log4J Logging Framework.limbus-properties
Core component to access property configurationslimbus-utils
Util module providing features for accessing ZIP archives and reflective operations.limbus-staging
Module for developing integration tests and bootstrapping of an embedded Limbus Engine instancelimbus-system
Core component managing system componentents as well as an implementation of a Dependency Injection (CDI) mechanism.limbus-task-scheduler
System component managing periodically called tasks supporting adaptive scheduling intervals.limbus-vfs
System component providing an API for the file system abstraction. Provides an implementation to access the real filesystem and an implementation providing an in-memory file system for easy support of integrations tests
Compatibility with Java 9 and later
Currently the Limbus Engine performs a few class-leak prevention operations like scanning the ThreadLocals that were created but not freed by plugin code. Those operations use reflective access to 'java.base' module. By default this is not allowed in Java 9 and later.
Currently there is no switch to disable this features in Limbus Engine. So currently use the following argument when starting a JVM:
--add-opens java.base/java.lang=com.remondis.limbus.engine.implementation
Leak Prevention notes
Currently ThreadLocal and ClassLoaders are scanned for possible classloader-leaks. Maybe some of those hacks are not necessary.
- ThreadLocals are held using a WeakReference. Those references should clear themselves if no other stronger reference is existent. Maybe the operation in
com.remondis.limbus.engine.LimbusUtil.getCurrentThreadLocals()
is not needed anymore.