Declaring a service as Lazy

When a bundle registers a service as lazy, the framework registers the service without actually starting the bundle until there is another bundle requesting the provided service object.

Of course, a service provider bundle can register non-lazy services as well - they are handled in the conventional OSGi-defined way.

Declaring specific services of a bundle as "lazy" can be done by using a special header in the bundle manifest, called Provided-Services.

Provided-Services ::= lazy_clause (',' lazy_clause)*
lazy_clause ::= class (';' class)* (';' property)*
class ::= 'class=' <fully_qualified_class_name>
property ::= key '=' value
key ::= string
value ::= string

For example:

• Provided-Services: class=com.prosyst.util.pcommands.PluggableCommands;group=kitman;description=Provides the Kit Manager commands

As a single URL Stream Handler service may support more than one URL scheme, as well as a single Content Handler service may handle more than one content type, in a lazy service declaration you can use the "$" separator to specify several values to the url.handler.protocol property for a URL Stream Handler and to the url.content.mimetype property for a Content Handler.

Requirements for a Lazy service

Requirements which you should follow in order to register a working lazy service.

1. Interface Classes Matching – All interfaces that are declared in the Provided-Services manifest header for a lazy service must match exactly to all interface classes specified in the real service registration.
2. Properties Matching – The properties in the lazy service declaration within the Provided-Services header must match the ones provided in the real service registration (keys are not case sensitive). In addition, the real service is allowed to have more properties than the lazy one.
3. Registration Requirement – The service provider bundle must register the lazy service in the terms of the OSGi Framework Specification (by using the registerService method of the corresponding BundleContext) during startup (in the body of the activator's start method).

Defining a Lazy service condition in a bundle

Service consumer bundles can declare a specific condition on the availability of a service with specific properties. If the condition is not satisfied (that is because, the service does not present in the service registry), the framework starts Lazy the bundle. When the service(s) matching the condition become registered, the bundle enters the conventional "Active" state.

Similarly to declaring a lazy service, a lazy start condition in a service consumer bundle can be defined in the manifest header - Lazy-Filter, which should contain an LDAP filter for registered services compliant with the OSGi Service Platform Core Specification.

For example:

• Lazy-Filter:    (&(|(objectclass=org.osgi.service.Device)(DEVICE_CATEGORY=*))       (objectclass=org.osgi.service.Driver))

Defining a Lazy manifest condition in a bundle

A bundle may use specific type of bundles, indicated through the presence of a specific manifest header with specific content. If there is no bundle containing the declared manifest information, the manifest dependent bundles are started lazily. A lazy start condition in a manifest dependent bundle can be defined again in a manifest header – Lazy-ManifestFilter, which should contain an OSGi-compliant LDAP filter for specific content of manifest headers.

For example:

• Lazy-ManifestFilter:   (|(Bundle-SymbolicName=com.prosyst.mbs.osgi.useradmin)      (Bundle-Name=*com.prosyst.mbs.useradm.jar))

To achieve a better performance, you may include in the mbs.bundles.cacheHeaders system property the manifest headers used as filter attributes. In such case, the framework will cache the header and will execute the check operation faster.