[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers

Overall I agree with Neil but have some nit-like comments that may be relevant...

Neil Bartlett wrote on 03/30/2006 07:50:21 AM:

> "Installed" means that the bundle has been installed into the runtime
> but some or all of its dependencies (ie both through Requires-Bundle
> and Import-Package) could not be resolved yet.
> "Resolved" means that the bundle is installed AND all of the bundles
> named in Requires-Bundle are installed AND all of the Import-Packages
> have been wired to a corresponding Export-Package in an installed
> bundle.

the prerequisite bundles (either via require or import) must be *resolved* for the dependent to be resolved.

> "Active" merely means that a Resolved bundle has an Activator and the
> start() method has been called by the framework. In pure OSGi terms, a

Any bundle can be started.  Having an Activator is not a prerequisite.

> bundle is only activated if another bundle asks the framework to start
> that bundle, for example if the user types "start 10" in the OSGi
> console. Equinox also has the Eclipse-LazyStart directive which
> indicates that the bundle should be automatically started if any other
> bundle caused a class inside it to be loaded.

Yes, this is included to address scalability issues both in terms of performance (you dont want to start 1500 bundles at startup) and usability (figuring out which bundles need to be started in any give situation is hard)

> Typically a bundle that provides only Java classes (eg the interfaces
> for XML parsing) needs only to be Resolved and never Activated. A
> bundle needs to be Activated only if it registers services, consumes
> services from other bundles, or (in Equinox) registers extensions or
> extension points.

Extension/extension point use is completely independent of startedness.  You can remove the Eclipse-LazyStart header and not start the bundle yet still use extensions.  Also, some extensions do not contribute code so startedness is not relevant.

The key characteristic of needing to be started is if the bundle needs to proactively register itself in the environment or allocate resources.  For example, a bundle that implements and HTTP server needs to listen on port 80.  It may not have any services, extensions, ...  In the case of services you need an activator only so that you can get access to the BundleContext.  While many bundles do, there is no requirement that the services you supply be actually registered in your activator.  If we added the previously discussed mechanism for getting a context without an activator, the need for an activator would then be a pure lifecycle play.