[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] New equinox framework adaptor
- From: Thomas Watson <tjwatson@xxxxxxxxxx>
- Date: Thu, 13 Oct 2005 01:11:38 -0600
- Delivered-to: email@example.com
Since the Eclipse 3.0 release the Equinox
OSGi Framework has had a framework adaptor API. A framework adaptor
implementation is responsible for a number of tasks and is called upon
by the Equinox OSGi Framework to perform these tasks. The following
is an example of the tasks an adaptor implementation is responsible for:
1) Managing all persistent storage for
the framework. This includes:
- the storage of installed bundles and
all data associated with the installed bundles (active status, startlevel,
manifest headers etc).
- the resolution status and package
wiring for the resolved bundles.
- the assigned permissions (set through
PermissionAdmin and ConditionalPermissionAdmin)
- installing/updating/uninstalling the
associated bundle data.
- installation of native libraries
- creation of data files (requested
by the BundleContext#getDataFile method)
2) The implementation of the resolver
algorithm (an implementation of the State API from the org.eclipse.osgi.service.resolver
- implementing the resolver algorithm
is not for the faint of heart. I strongly suggest just using or extending
our implementation in the StateManager class
3) Creation of BundleClassLoaders. This
- management of bundle classpath (for
example, fragment attachment)
- searching for installed native libraries
- loading local classes/resources
- bundle classloader implementations
must delegate to the Framework first to allow for Import-Package/Require-Bundle
searches to occur first.
For Eclipse 3.0 and 3.1 releases the
adaptor API has allowed others to adapt the framework to add new functionality.
For example, the AspectJ team has used it to add runtime aspect class
weaving. In past releases in order to add new functionality in an
adaptor it was required that the adaptor implementation either re-implement
the complete framework adaptor API or extend one of the existing framework
adaptor implementations (AbstractFrameworkAdaptor, DefaultAdaptor or EclipseAdaptor).
This made it nearly impossible for two 3rd parties to add in new
functionality to the framework in an adaptor. The Equinox OSGi Framework
can only be configured to use one adaptor. If there are two framework
adaptor implementations which provide unrelated functionality it is impossible
to configure them both to be used at the same time.
For the Eclipse 3.2 release we would
like to overcome this limitation. A new adaptor implementation is
being developed which allows framework extensions to add in new hooks to
perform specific tasks for the adaptor implementation. The framework
adaptor API i remains unchanged for the most part in Eclipse 3.2. What
is changing is the actual implementation of the adaptor API (the new adaptor
implementation will be referred to as the EquinoxAdaptor from now on).
The EquinoxAdaptor will replace the existing framework adaptor implementations
provided by the Eclipse team (AbstractFrameworkAdaptor, DefaultAdaptor
and EclipseAdaptor). The EquinoxAdaptor allows others to hook in
additional functionality into the adaptor implementation in the form of
I have released an initial implementation
of the EquinoxAdaptor in the equinox-incubator. You can extract the
EquinoxAdaptor project (org.eclipse.equinox.adaptor) using the following
cvs server information:
Repository root: /cvsroot/eclipse
Any input on the EquinoxAdaptor API
would be a great help. In particular from the AspectJ team and any
others who have their own adaptor implementation (Chris Laffra).
To self-host eclipse using the EquinoxAdaptor
use the following step:
1) Extract the latest org.eclipse.osgi
code from HEAD into your workspace
2) Extract the org.eclipse.equinox.adaptor
project from the equinox-incubator into your workspace
3) Create a new Eclipse Application
or Equinox OSGi Framework launch configuration.
4) In the new launch configuration add
to the VM arguments
5) Run the new launch configuration
Note that the framework extension bundle
(org.eclipse.equinox.adaptor) must co-exist in the same location as the
framework (org.eclipse.osgi). This is why it is required to have
the org.eclipse.osgi project in your workspace to self-host with the EquinoxAdaptor.
The EquinoxAdaptor offers a set of hook
interfaces which may be implemented and configured to perform specific
tasks. The following is a list of hook interfaces which are available
for the EquinoxAdaptor:
EquinoxAdaptorHook: hooks into the overall
lifecycle of the adaptor. The following tasks may be provided by
an the EquinoxAdaptorHook
- set framework properties
- execute code when the framework is
starting/stopping/stopped (to register/unregister services etc.).
- handle runtime errors
BundleFileFactory: hooks into the BundleFile
creation. A BundleFileFactory is asked to create BundleFile objects
for a given EquinoxData and content object.
EquinoxDataHook: hooks into methods
of the BundleData interface
- when startlevel is changed
- when active status is changed
- when searching for native code
- when matching patterns against the
DN certificate change used to sign the bundle
EquinoxLoaderHook: hooks into the EquinoxLoader
- before a class is loaded
- after a class is loaded
- before a resource is loaded
- after a resource is loaded
- to add classpath entries
- to process class bytes
EquinoxStorage: handles all persistent
storage for the framework. Unlike other hooks, only one EquinoxStorage
implementation may be configured with the EquinioxAdaptor. But there
is an EquinoxStorageHook which can be used to store additional data in
an EquinoxStorage implementation.
EquinoxStorageHook: hooks into
an EquinoxStorage implementation to store additional data for a bundle.
BundleWatcher: gets notified when a
bundle is activated/deactivated
All of the above hook interfaces (except
BundleWatcher) are included in the org.eclipse.equinox.adaptor.hooks package.
Each hook is configured into the EquinoxAdaptor by an EquinoxHookConfigurator.
An EquinoxHookConfigurator adds hooks to the hook store for the EquinoxAdaptor
(EquinoxHooks class is the hook store for the EquinoxAdaptor). The
EquinoxHooks class will load each EquinoxHookConfigurator and call on it
to add hook implementations.
Attached is a simple framework extension
which configures an EquinoxLoaderHook to print class/resource load requests
to standard output. Import the simpleloaderhook project into the
same workspace with the equinox adaptor project and edit the launch configuration
to add the framework extension to the VM args:
Description: Zip archive