The Carbon Core Bootstrap Subsytem

The purpose of the boot strap system is get the system up and running. This means that the system is ready to serve components and configuration to clients. It encapsulates the knowledge of how to call the startup methods of Configuration and Component subsystems and where to find the minimum information required for these subsystems to start.

Replacable Loading

The system must be configurable such that the implementation of the system loader can be changed.

Keep static class small

The functionality of loading the system should be kept out of the static singlton entry class. The singleton class should only provide and entry point to the bootstrap system and synchronize requests.

Enough info to start config

Must be able to find on its own the minimum amount of information to start the system (to start configuration and component subsystems and startup components).

Load only once

Repeated calls to the bootstrap system should not load Carbon more than once.

Lazy loading

The bootstrap system should load Carbon when the services of the Carbon system are required, not before.

Support Non-Lazy loading

The bootstrap system should have an easy way to start the load sequence.

Load Startup Components

The bootstrap system should allow a list of components to be specifed which will be created as part of the boot sequence. If this list is missing, this step should be ignored.

The entry point to the boot strap system is the BootStrapper singleton class. It is meant to be called by either the Component or the Configuration Services (for lazy loading) or by a startup class.

The startup sequence has 3 steps:

• Start the Configuration Service
• Start the Component Service
• Load any components listed as startup components

The Configuration Service is started using a minimum amount of configuration drawn from the Deployment Properties (see Deployment Properties). Once the Configuration Service is started, it is used as the source of configuration needed to start the Component Service. Once the Component Service is started, the Startup Service component is fetched and all components configured to start are started.

The Carbon Startup sequence is triggered by the first request to the Configuration or Component Services unless the Bootstrap subsystem is explicitly called to load. The startup sequence is synchronized so that only one thread will load Carbon while all others wait. The startup sequence will run only once.

Each step relys on the results of the previous steps. The Component Service needs configuration. Startup components need configuration and are created by the Component Service.