|Re: [equinox-dev] New equinox framework adaptor|
Best regards, Martin
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 package).
- 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 includes:
- 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 equinox hooks.
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:
Host: dev.eclipse.org Repository root: /cvsroot/eclipse Module: equinox-incubator/org.eclipse.equinox.adaptor
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 "-Dosgi.framework.extensions=org.eclipse.equinox.adaptor" 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:
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
Description: Zip compressed data
Description: S/MIME Cryptographic Signature