Introduction
This page describes how the ApacheDS bootstrap plugin for Maven works in conjunction with the various bootstrappers using the single software installation path with many instances configuration.
Bootstrap Framework
There are many daemon frameworks out there: jsvc, tanuki, and jrun. There are more but we have not written bootstrappers for them. However writing a bootstrapper for a new framework should be pretty simple to do thanks to this framework composed of the installer generating Maven plugin and the runtime interfaces and classes.
Before we go any further into the framework, please realize that this code has been devised for network server daemons like an LDAP server. The framework was not intended for use with generic non-server type applications. It can be adapted to suite them as well however this would chew up the code. It's best to just have this framework do what it does and do it well..
DaemonApplication Interface
The DaemonApplication interface declares life cycle methods that implementations use to init(), start(), stop(), and destroy() the service. The daemon framework will invoke init() then start(). The instance of the DaemonApplication that is instantiated on startup survives for a long time. When calling stop() and destroy() the instantiation occurs again in a separate process while the first instantiation is still running. Meaning, the same object instance is not invoked when the service is stopped, neither is it even in the same process.
Bootstrappers
Each framework may have it's own Java interface for starting and stopping the Java service. Regardless of what method is called to start or stop the Java service the Bootstrapper translates these calls into calls against the DaemonApplication interface. Each framework's bootstrapper will have it's own bootstrapper class which extends Bootstrapper. The Bootstrapper base class has some reusable methods for instantiating and invoking methods on the DaemonApplication. Most Bootstrapper extending classes can reuse these methods instead of implementing their own.
The bootstrapper is usually instantiated by the daemon process for the framework after starting up a JVM. Also most bootstrappers will in addition to calling start() will invoke init() first even if the framework does not have init() in it's life cycle. Sometimes the subclass of Bootstrapper will implement framework specific interfaces to work with the framework. In the top picture to the right you can see the steps in this invocation process which occurs on start requests to the framework.
When stopping the service a new process is created with a new JVM. When the bootstrapper is instantiated it is not the same bootstrapper object that was used to start the server. This is what messes most with peoples heads. Then how do we properly invoke a stop on the original server that was started?
The base Bootstrapper class contains
