|
|
|
|
|
Startup
If a bundle is lazy, it declares a lazy service or a manifest condition. Its start includes only registering the lazy service or condition in the service manager, respectively, and setting its state from RESOLVED to ACTIVE.
Processing Lazy services
The framework performs the following operations for a lazily-registered service:
When the real service registration takes place at bundle startup, the framework checks if the service is registered by a lazy bundle and all registration properties match.
A real service registration is considered as equal to a lazy service declaration only if the object classes are equal and the properties in the lazy declaration match the real service's properties.
On success, the framework returns a lazy service registration object to the service provider bundle. Otherwise, the registration object for the lazy service is null.
If the start method of the bundle activator succeeds, then all bundle's lazy services are initialized.
If a lazy service is not initialized, check the Provided-Services manifest header for errors.
Handling bundles with Lazy conditions
If the Lazy-Filter or Lazy-ManifestFilter header is present in a bundle’s manifest, then an LDAP Filter is created by using the "lazy" manifest field. This filter is registered in the Service Manager or in the Bundle Manager, and when all conditions described in it are fulfilled, the bundle is started and its classes loaded.
Delivering events
The framework provides registered service listeners with the following event notifications related to lazy initialization of service:
Managing Lazy bundles in a programming way
You can use the Framework Access service (com.prosyst.mbs.framework.access.FrameworkAccess) to check if a bundle is lazy and if a service is lazily registered, and to start a lazy bundle by preserving its lazy features.