[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] New equinox framework adaptor

Hi Thomas,

Yes, you should use the org.eclipse.osgi from the general eclipse repository. I prefer to keep a majority of my work done in the Eclipse proper (HEAD) stream, unless it is going to be a long term project that may not go into the current release of Eclipse. The small changes I made to org.eclipse.osgi in HEAD just allow for other adaptors to work with eclipse that do not extend the EclipseAdaptor. This was needed to allow for the new EquinoxAdaptor to work. I view this as a small change to org.eclipse.osgi that should go into Eclipse 3.2 regardless of whether the new EquinoxAdaptor makes it into 3.2. Let me know if you run into any issues running the EquinoxAdaptor.

Ah, now I understand this in more detail. Thanks a lot for your explanation and sorry for still being somewhat unoriented regarding the code repository structures. Still a newbie in this area...


But that brings up another question (from the newbie ;-): I understand that there might be code differences between the incubator area and the HEAD. But is there any policy who/when/how to migrate changes from HEAD back into the incubator area?

Thanks for the help!!!
-Martin




Thanks.

Tom




Martin Lippert <lippert@xxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
10/21/2005 08:04 PM
Please respond to
Equinox development mailing list



To Equinox development mailing list <equinox-dev@xxxxxxxxxxx> cc

Subject
Re: [equinox-dev] New equinox framework adaptor






Hi Thomas,

haven't tried too much yet but what confused me was that I needed the org.eclipse.osgi bundle from the general eclipse repository instead of the one from the incubator area to try this...

-Martin



Thomas Watson wrote:
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:


-Dosgi.framework.extensions=org.eclipse.equinox.adaptor,org.eclipse.equinox.examples.simpleloaderhook

Tom





------------------------------------------------------------------------

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev




------------------------------------------------------------------------

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev