Previous Topic

Next Topic

Book Contents

Book Index

XML syntax for startup bundles lists

The startup bundles list files have 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 XML DTD for a startup bundles list is as follows:

DTD element

Description

<!ELEMENT main (section*)>

The root element of the Startup Bundles List 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. If using relative paths, the base directory is determined by the mbs.bundles.base system property. The default one is "bundles".

<!ELEMENT level (#PCDATA)>

The initial start level of the bundles in the group. The bundles of this section will be started if this level is less than or equal to the start level of the framework (it is "5" by default).

<!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:

  • "install" - Installs a bundle given the location of its JAR. Several options are supported:
    • -S - installs all bundles in a section and then starts them.
    • -s - starts each bundle right after it is installed.
    • -f - installs all bundles in a section "from file".
    • -l - installs each bundle taking into account its activation policy at the bundle subsequent start, affecting policy specified either in the Bundle-ActivationPolicy manifest header, defined by the OSGi Core Specification, or in the manifest headers Provided-Services, Lazy-Filter and Lazy-ManifestFilter, introduced additionally for lazy initialization (see "Lazy Initialization").
    • -t - installs each bundle taking into account its activation policy at the bundle subsequent start and preserving the resulting autostart setting across bundle restarts. See the description of the previous option for information about determining the activation policy.
    • -d <dir_name> - installs each bundle "from file" storing it in the specified destination - the bundle JAR file is placed in a bundles subdirectory and the manifest and data files - in a data directory. It is not necessary to additionally specify the -f option.
    • -R - tries to resolve all bundles in a section after installing all of them.
    • -r - tries to resolve each bundle right after it is installed.
  • "start" - Starts a bundle with specified either location or bundle ID (specifying the location is the preferred way). You might use several options to the "start" action:
    • -l - starts each bundle taking into account its activation policy. This option has the same meaning as the -l option of the "install" action.
    • -t - starts each bundle taking into account its activation policy and preserving the resulting autostart setting across bundle restarts. This option has the same meaning as the -t option of the "install" action.
  • "uninstall" - Uninstalls the bundles listed in the section.

<!ELEMENT bundle (name, permission*)>

A bundle on which the actions from the section will be applied.

 

The "permission" element is deprecated and its usage is discouraged.

<!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.