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


Hi Martin,

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.

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