[rfc 124] Blueprint and lazy activation

[bjhargrave]

Original bug ID: BZ#862 From: @bjhargrave Reported version: R4 V4.2

[bjhargrave]

Comment author: @bjhargrave

Lazy activation was added to the OSGi core spec in 4.1 (see section 4.3.7.1).

The OSGi Declarative Services spec was updated to allow DS to work with bundles that are lazily activated. (see bug BZ#791 for a DS spec defect where the 4.1 DS spec was no updated for this).

How does Blueprint work with Lazy Activation bundles? Will Blueprint process contexts for lazily activated bundles? While they sit in the STARTING state?

Is Blueprint lazy at class loading to delay activation for lazy activation bundles? Or is Blueprint an eager at loading classes?

Details on how Blueprint and Lazy Activation interact need to be in the rfc/spec.

[bjhargrave]

Comment author: Adrian Colyer <acolyer@vmware.com>

The Blueprint Service is currently specified to trigger module context creation on a Bundle STARTING event. Therefore, if a bundle has a lazy activation policy, module context creation will not occur until a class is loaded from the bundle.

There are a few factors to consider here:

• A module context that publishes services will not publish those services until a class is loaded from the defining bundle
• Having some mode that says "create the module context eagerly" will, in the vast majority of cases, force a class load, and is effectively the same as saying "ignore the lazy activation policy". Given that, I think it would be better to just not specify a lazy activation policy!
• At the module context level you can already mark all components as lazy by default, and you can mark individual components as lazy if needed

The gap in lazy behaviour that I can see is that it might be nice to allow service lookup of a service that would be published by a module context were the module context active to trigger module context creation for bundles that are in the STARTING state but have not yet issued a STARTING event. An implementation would need to listen to LAZY_ACTIVATION events, parse the module context configuration and determine the services that would be published, and then register a service hook for those services. Some complications to consider here since service properties can come from property placeholder configurers and these won't be instantiated if the module context is not yet created...

[bjhargrave]

Comment author: Adrian Colyer <acolyer@vmware.com>

Added the following text to the section on the element (5.4.1)

When a bundle specifies lazy activation in its Bundle-ActivationPolicy manifest header, and that bundle is started with the “START_ACTIVATION_POLICY” flag set, then the bundle will wait in the STARTING state until the first class load from the bundle occurs. For a bundle with a module context blueprint that defines one or more services, this means that without special treatment, none of these services would be visible until a class load occurs. An important use case is to enable the first dereference of a service reference to trigger creation of the module context. For a bundle that specifies the lazy activation policy and is started accordingly, the following steps are taken: • The OSGi Service Platform creates a BundleContext object for the bundle • The bundle state is moved to the STARTING state • The LAZY_ACTIVATION event is fired • A synchronous Blueprint Service event listener receives the LAZY_ACTIVATION event o The configuration metadata for the bundle is parsed, and any service elements are detected o For any service that can be lazily registered, a lazy ServiceFactory is registered in the service registry to represent that service  A service can be lazily registered if the interface or interfaces under which the service is to be registered are explicitly specified and are Java interface types, and there are no registration listeners defined.  The lazy service advertises the same interfaces and properties as the ‘real’ service that will be created when the module context is created. o No components from the module context are instantiated during this process o The synchronous event listener returns From this point, there are two triggers that can cause the module context to be created: a class load from the bundle, or a dereferencing of the ServiceReference for a lazy service.

In the first case: • The system waits for a class load from the bundle to occur • The normal STARTING event is fired o Asynchronous creation of the module context begins  Any lazy ServiceFactory objects registered during LAZY_ACTIVATION are updated to return the true services defined in the module blueprint. • The bundle is activated • The bundle state is moved to ACTIVE • The STARTED event is fired

In the second case: • The ServiceFactory method getService is invoked on a lazy service (because a client has passed the ServiceReference obtained from the registry to the BundleContext.getService operation). o Synchronous creation of the module context begins  Any lazy ServiceFactory objects registered during LAZY_ACTIVATION are updated to return the true services defined in the module blueprint o Module context creation completes o The getService operation returns the true service from the module context

Note that the potential for race conditions exists under concurrent class loading and/or service access. An implementation of the Blueprint Service must ensure that only one module context is instantiated under such conditions.

[bjhargrave]

Comment author: Graham Charters <charters@uk.ibm.com>

I think there needs to be some text covering how lazy activation relates to module contexts which have unsatisfied mandatory service references. Currently the timeout is measured relative to the STARTING event. For lazy activation, the timeout needs to be measured relative to the LAZY_ACTIVATION event.

[bjhargrave]

Comment author: Adrian Colyer <acolyer@vmware.com>

I added the following step at the second point in the lazy activation algorithm: (5.4.1.6)

o The Blueprint Service waits for any mandatory service references of the context to be satisfied, according to the rules discussed in section 5.2. Once the services are satisfied:

In addition I added the following text to section 5.4.3.1:

"Automatic service registration and unregistration also applies to lazily registered services that have been registered on behalf of a bundle with a LAZY_ACTIVATION policy."

These changes are included in the 0.9.8 draft of the specification.

[bjhargrave]

Comment author: Graham Charters <charters@uk.ibm.com>

I added the following step at the second point in the lazy activation algorithm: (5.4.1.6)

o The Blueprint Service waits for any mandatory service references of the context to be satisfied, according to the rules discussed in section 5.2. Once the services are satisfied:

I'm afraid I don't quite understand this part. Particularly the "Once the services are satisfied:". I think there needs to be an explicit mention that the timeout is relative to the LAZY_ACTIVATION event, not STARTING, which is what is described in 5.2.

I hope that makes sense.

[bjhargrave]

Comment author: Adrian Colyer <acolyer@vmware.com>

Added this qualification as suggested in draft 0.99.