Description Glyn Normington 2010-11-10 08:00:10 EST

Scenarios such as that described in the linked article on "Running RAP on Virgo" are complicated by the Jetty Http Service bundle being marked for lazy activation. When the bundle is started, it enters the STARTING state until either a class is loaded from the bundle or another start request is sent to the bundle.

Lazy activation is designed for situations where users of a bundle will load at least one class from the bundle before expecting to be able to use the bundle. During the class load, the bundle start processing completes and the bundle state changes to ACTIVE. So, by the time the class load request has returned, the bundle is available for use. The advantage of this is that fewer resources are consumed by the bundle until it is about to be used.

However, the Jetty Http Service is used in the above scenario, and presumably many others given that it only exports the Equinox-specific package org.eclipse.equinox.http.jetty, *without* any classes being loaded from it by other bundles. So the Jetty Http Service has to be started *again* before it is ready for use.

The Jetty Http Service bundle would therefore be more usable if it did not specify lazy activation.

Compare bug 329571 for a similar improvement which was made to the Jetty "osgi.boot" bundle.

The behaviour may be reproduced by following the steps on the RAP wiki in the linked article. After deploying the RAP demo plan, the Jetty Http Service is stuck in (lazy) STARTING state:

33	<<LAZY>>    org.eclipse.equinox.http.jetty_2.0.0.v20100503

until the user manually starts it (for a second time, because Virgo has already started it once).

(It has been suggested that Virgo add a mechanism to double-start bundles which specify lazy activation but which need starting again, but there is no need for such a mechanism for lazy activation bundles which are designed to require a class to be loaded from them before they are used, which is how the OSGi spec describes lazy activation.)