Difference between revisions of "Equinox/Luna Framework"

Revision as of 11:03, 18 July 2013

Overview

The Equinox Framework for the Luna release (Equinox 4.4 release) is an implementation of the OSGi R6 Framework specification. The OSGi R6 Core framework specification (finalized in March 2014) will contain enhancements in the following areas:

• Introduction of Service Scopes to the OSGi Service Registry (RFC 195)
• Improvements of Weaving Hooks (RFC 191)
• Clarification of hooks on the system bundle (RFC 198)
• Native environment namespace (RFC 188)
• Data Transfer Objects (RFC 185)
• Addition of FrameworkWiring.findProviders

These are considered incremental enhancements and from the Equinox perspective. Most, if not all, of these enhancements are in place for the Luna M1 build. A majority of the development effort during the Luna release is focused on refactoring and in many cases rewriting the core Equinox Framework implementation to be based on the OSGi generic dependency model. There are a number of reasons to do this. Please see the Equinox presentation given by Tom Watson at EclipseCon US 2013 for some background.

Replacing the Equinox Resolver

The package org.eclipse.osgi.service.resolver contains the Equinox resolver API. This API and the implementation of that API has been used by the Equinox framework ever since the Eclipse 3.0 release. Over that time many things have changed and many things have been learned. In short the Equinox Resolver API and it use came about as an afterthought for the framework implementation and had to evolve over time as changes were made to the OSGi Core Framework specification. The end result is not optimal (to put it lightly). There are many issues with the interactions of the core framework with the resolver implementation.

• A good locking strategy for thread safety is not well thought out and in some cases non-existant.
  • This results to several, hard to reproduce dead-locks, or concurrency issues.
• The Equinox resolver API is strongly typed with respect to dependency types.
  • This means that each time OSGi introduces a new type of requirement then new API is required to be added to the Equinox resolver API.
  • A few OSGi specification releases ago the specification moved to defining all OSGi dependency types in terms of a generic dependency model. This makes the current implementation, using strongly typed dependencies, awkward when considering the core concepts of the core specification.
  • Along with the generic dependency model came a new wiring API. This wiring API more accurately models the dependencies in OSGi and is a replacement for the deprecated PackageAdmin service.
  • The equinox resolver has to do many transformations in order to express the internal strongly typed dependencies into generic wiring types.

Instead of trying to live with the strongly typed resolver API and do major work to implement an overall locking strategy, we have decided to stop using the equinox resolver API altogether in the framework implementation. We have implemented a container which is used to manage (install, uninstall, update) generic metadata.

The container becomes the central brain of the core framework implementation and is responsible for the following:

• Managing resources
  • Access to meta-data, in the form of generic capabilities and requirements from the OSGi wiring API.
  • Lifecycle operations (install, update, start, stop, uninstall)
  • Persistences of the state of the container
• Resolving dependencies
  • Uses an OSGi R5 Resolver service
• Provides a central concurrency and locking strategy
  • Properly handle call outs (hooks) while holding no locks
  • Allow for re-entrant read/write locks that allow for multiple readers to access the data.
• Provides a generic API that can be used outside the framework

For the framework, the meta-data associated with a revision comes from a bundle's manifest, but the meta-data installed into the container does not care how the meta-data is declared. A module revision builder is used to create bundle a revision for installation and update of revisions in the container.

Redoing the Equinox Framework Specific Hooks