[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] IWeavingServiceFactory.createWeavingService takes a BundleDescription

Hey Tom!

I worked on your branch yesterday and today and got Equinox Weaving to work - which is great. So thanks a lot for making all those old hooks available!!!

I had to change a few things inside the equinox weaving hook fragment, since it made too many implicit assumptions on how and when the framework does some bits and pieces. The most notable change that I came across was that classloaders seem to be created eagerly now, right after the simpleconfigurator ran, but before any other bundles are started.

I changed the way the equinox weaving hook fragment works inside, so that is not a real problem. However, I would love to hear your opinion on this:

- the weaving.hook fragment doesn't do any weaving or caching itself. It just provides the infrastructure bits and pieces. Therefore it creates a service tracker to get hold of the concrete weaving (in our case, it is this AspectJ weaving implementation).

- but that requires the o.e.e.weaving.aspectj bundle to be installed and started right away, before other bundles are doing any classloading (to be able to weave a much as possible of the system and to be as deterministic as possible)

- at the moment this is done by setting a start level of 4 to that bundle and mark it as started (via p2.inf in case it gets installed). In my self-hosting workspace, I start it with a start level of 1 at the moment. That seems to work to a certain degree. A certain set of bundles have been used already for classloading before my weaver bundle registered its service.

What do you think is the best way to configure or solve this?

The weaver bundle itself depends on a few other bundles (like the aspectj-bundles themselves), so it is obvious that those bundles cannot be woven. But everything else should be possible.

Any thoughts?


P.S.: I also noticed that I had to set -Dosgi.framework.extensions with an absolute path via reference:file: to the weaving hook (in my self-hosting setting). Is that correct or am I doing something wrong?

On 15.03.13 19:48, Thomas Watson wrote:
Just to let you know I found a bug in the new container [1].  It was not
informing the class loader hook about a newly created module class
loader.  I suspect this would cause the equinox weaving hooks to not work:

[1] -


Inactive hide details for Andrew Eisenberg ---03/08/2013 03:34:50
PM---Hi Tom, Thanks for taking a look at this. AJDT is one oAndrew
Eisenberg ---03/08/2013 03:34:50 PM---Hi Tom, Thanks for taking a look
at this.  AJDT is one of the main consumers

From: Andrew Eisenberg <andrew@xxxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date: 03/08/2013 03:34 PM
Subject: Re: [equinox-dev] IWeavingServiceFactory.createWeavingService
takes a BundleDescription
Sent by: equinox-dev-bounces@xxxxxxxxxxx


Hi Tom,

Thanks for taking a look at this.  AJDT is one of the main consumers
of org.eclipse.equinox.weaving.hook through the
org.eclipse.equinox.weaving.aspectj bundle.  It looks like you have
also updated the org.eclipse.equinox.weaving.aspectj bundle.  I will
get a chance to try this out next week.  Just to be sure, if I check
out this branch of equinox and drop the osgi bundle into Kepler, will
things hang together?


On Fri, Mar 8, 2013 at 12:57 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
 > Keep in mind this is a discussion for Luna, not Kepler.  I have been
 > spending some time lately around the new framework implementation
based on
 > the OSGi R5 generic capability/requirement model.
 > I was looking at porting the Equinox weaving hooks
 > (org.eclipse.equinox.weaving.hook) over to a new Equinox framework
 > implementation that is based internally on the generic
 > capability/requirement model of the OSGi R5 specification.  This
 > implementation no longer is based on the old Equinox resolver API
 > (org.eclipse.osgi.service.resolver).  As such the weaving hook
 > implementation no longer has access to BundleDescription objects or a
 > object at runtime.  Instead it would have access to
 > org.osgi.framework.wiring.BundleRevsion/BundleWiring objects.
 > How disruptive would it be to make a breaking API change to
 > org.eclipse.equinox.service.weaving.IWeavingServiceFactory to take a
 > org.osgi.framework.wiring.BundleRevsion instead of the old
 > org.eclipse.osgi.service.resolver.BundleDescription and no longer take a
 > org.eclipse.osgi.service.resolver.State?
 > I noticed the bundle org.eclipse.equinox.weaving.hook exports the package
 > org.eclipse.equinox.service.weaving with no version (defaulting to
 > For the next release I suggest we bump this version to 1.0.0 and
indicate a
 > breaking change for implementors of
 > org.eclipse.equinox.service.weaving.IWeavingServiceFactory.  I'm not sure
 > how many others outside of the org.eclipse.equinox.weaving.aspectj bundle
 > implement this interface.  But without this type of change I see no
way to
 > support Equinox Weaving on the new framework.  Beyond this I still want
 > someone to investigate moving as much of the Equiniox weaving hooks
onto the
 > standard OSGi WeavingHook services [1].
 > If you want to see the work I have done so far then load up the
 > twatson/container branches from both the rt.equinox.framework [2] and
 > rt.equinox.bundles [3] git repositories.  You should be able to self-host
 > Eclipse if you load up the framework project (org.eclipse.osg) and the
 > compatibility state project (org.eclipse.osgi.compatibility.state) which
 > provides an implementation of the old equinox PlatformAdmin/State
mainly to
 > support PDE.  I have not done any testing of the weaving hook changes.  I
 > only spent the morning getting rid of compile errors which pointed me to
 > this API issue with BundleDescription in the Equinox Weaving API.
 > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377422
 > [2]
 > [3]
 > Tom
 > _______________________________________________
 > equinox-dev mailing list
 > equinox-dev@xxxxxxxxxxx
 > https://dev.eclipse.org/mailman/listinfo/equinox-dev
equinox-dev mailing list

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