Version 4.1 changes to OSGi Core Specification

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.

JSR 291 is final

As mentioned on Glyn's blog JSR 291 is now final. The most important point here is that OSGi Service Platform Release 4 Core Specification Version 4.1 (quite a mouthful) is done and published. JSR 291 adds some icing to that cake by having a final JSR specification for the OSGi core spec. So, for those who like their Java specifications with a JCP flavor, OSGi technology is now also available in that flavor. :-)

You can access the JSR 291 materials online now.

SD Times article on OSGi

An SD Times article on OSGi just came out in which I was interviewed. It is a really good article on OSGi and its stealthy uptake in the market. I really enjoyed chatting with the article's author.

What have I done?

Goodness! I've finally broken down and created a blog. To what is the world coming? After JavaOne this year, I realized I need to say some things about Java and OSGi futures and what better place than a blog? It is how we all communicate in the web 2.0 world.