Version 4.1 of the OSGi Core specification is a small incremental improvement to the already quite functional Release 4 specs. We made a number of minor enhancements, clarifications and errata fixes. But the 2 major changes in Version 4.1 occurred in the life cycle layer.
The two changes are (1) adding a transient flag to the Bundle start and stop methods and (2) adding a lazy activation mode to Bundle start.
1. Normally when Bundle.start() or Bundle.stop() are called, the framework must persistently remember the autostart setting of the bundle. That is, if a bundle is started with Bundle.start(), then, when the framework is next restarted, that bundle will automatically be restarted*. The start and stop methods have now been overloaded with new variants that take option flags. Two of these option flags control whether the start or stop action is transient. That is, whether the framework must alter the persistent autostart setting of the bundle. If the transient option is specified, then the framework does not alter the persistent autostart setting when performing the start or stop operation. See the new Bundle.start(int) and Bundle.stop(int) methods.
2. The other new feature is lazy activation. This allows the activation of a bundle (i.e. calling of the BundleActivator) to be delayed until the first class load is made from the bundle. This feature is based in large part upon the Eclipse-LazyStart capability. However there are a few important differences in the OSGi spec. In particular, we are clear to state that it is the activation that is lazy since starting bundle is still necessary, either explicitly via Bundle.start or implicitly because of the persistent autostart setting*. A bundle that is not started will never lazy activate. First it must be started, then it can lazy activate.
The spec also allows the caller of Bundle.start to ignore the lazy activation policy as declared in the bundle's manifest by using a new start option. This allows an admin agent to require "eager" activation even when the manifest says "lazy".
Finally, there is a new bundle event type that can be received by SynchronousBundleListeners to advise them that a bundle has started and is lazily awaiting activation. This can be used by extender bundles like OSGi Declarative Services, Spring OSGi and iPOJO to receive notification that the bundle has been started and now has a valid BundleContext. The extender bundle can then act on behalf of the bundle and do things like register services for the bundle.
Check out the new Version 4.1 spec for more details. It is now available for download.
* Assuming the bundle's startlevel is met.