Re: [equinox-dev] New equinox framework adaptor

[Martin Lippert <lippert@xxxxxxx>]

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