Boot INI and Boot Extension

By default, the framework and its Boot module use a boot INI file to learn which bundles should be automatically loaded at startup. If a custom boot extension exists, the framework will use it to perform the custom installation procedure of the extension (if implemented) and/or to get the boot INI file from a remote location.

Contents:

Overview of the Boot INI Content
Boot INI Location
Boot INI XML Syntax
Bundles Activated at Framework Startup
Boot Extension
References

Overview of the Boot INI Content

Basically, a boot INI file provides the following information about each bundle to be installed at framework startup:

Location of the bundle JAR
Initial start level - The start level of the bundle, used when the bundle is being started.
Action - The console command to be executed in order to load the bundle in the framework.
Permission - The permission that the bundle needs to operate correctly in a security-enabled framework.

Boot INI Location

The boot INI file can be in or outside the framework JAR. When started, the framework locates the boot INI file by using the mbs.boot.bootfile system property. The framework looks for the file outside the framework JAR considering the mbs.boot.bootfile value. If the mbs.boot.bootfile path is relative, it should be related to the directory where the framework is started, that is to bin/vms/<vm_name>.

If the system property is not set, the default value boot.ini is used. It points to boot.ini in the framework JAR (e.g. lib/serverjvm13.jar). This INI file contains the most important bundles for the operation of the other mBS bundles.

Boot INI XML Syntax

The boot INI has an XML syntax. The main functional unit of this XML is the section, which holds a number of actions and a list of bundles to execute the actions on.

The boot INI XML DTD is as follows:

DTD Element Description

<!ELEMENT main (section*)> The root element of the boot INI XML tree.

<!ELEMENT section (name, level?, strategy, bundle+)> Marks the beginning of a section.

<!ELEMENT name (#PCDATA)>

The name of the section. Usually, it corresponds to the category of the bundles included in the section. For example osgi.
The JAR location or ID of the bundle.

<!ELEMENT level (#PCDATA)> The initial start level of the bundles in the group.

<!ELEMENT strategy (action+)> The list of the actions (commands) to execute on the section bundles at startup.

<!ELEMENT action (#PCDATA)>

The action to execute on the section bundles. Supported actions are similar to the fw group commands.

Action	Description
install	Installs a bundle given the location of its JAR. Three options are supported: -S that installs all bundles in a section and then starts them. -s that starts each bundle right after it is installed. -f that installs all bundles in a section "from file". -l that installs each bundle taking into account its lazy services or start conditions.
start	Starts a bundle with specified either location or bundleID (specifying the location is the preferred way).

<!ELEMENT bundle (name, permission*)> A bundle on which the actions from the section will be applied.

<!ELEMENT permission (#PCDATA)>

A permission to preliminary assign to this bundle when the framework is started with security.

The "permission" element has the format:
(<permission_type> "<permission_name>" "<action>[,<action>]")

where <permission_type> is the class name the requested permission; <permission_name> is the target of the permission, for example a package name for an org.osgi.framework.PackagePermission; and <action> is the action to perform on the permission target. The <permission_name> and <action> are specific for every permission type.

Bundles Activated at Framework Startup

According to the Framework Version

The framework starts the following bundles in the Standard Version of the framework (listed in order of installation):

When the Connector Version of framework is used (the boot INI for this framework version is bootconn.ini), the framework activates the above bundles using their mio suffixed JARs where necessary. It does not load the Connector Service Bundle as its functionality is provided by the System Bundle.

According to the Current JVM

There is a special boot INI which should be used when the framework is run on J9 with JXE support - jxe.ini from lib/serverj9.jar.

According to the Lazy Mode

When the framework is started in lazy initialization mode, a special boot INI should be used - lazy_boot.ini from lib/server*.jar and lazy_jxe.ini from lib/server*.jxe.

Boot Extension

Developers and system integrators can customize the logic for installing bundles at framework startup by developing own boot extensions. Another feature that a boot extension can have is delivering the content of a boot INI file published at a remote location.

A boot extension should implement the com.prosyst.mbs.framework.boot.Boot interface. A boot extension can:

Introduce installation logic different from the one integrated in the framework, i.e. from getting the initial bundles from a boot INI file. Implement the needed operations in the performInstall method by using the BundleContext of the System Bundle, passed as method's argument.
Provide access to a boot INI file available at a remote URL. Implement the getBootINI method returning an input stream to the remote boot INI.

Next, to make the framework use your boot extension, prior to starting the framework add the extension class to the JVM classpath and set the mbs.boot.extension system property to the name of the boot extension implementation class.

References

Framework Architecture