Skip to main content

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

> From: Martin Lippert <lippert@xxxxxxx>
> 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!!!


Great, glad you got it working!

>
> 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:


I think I found the change in behavior here.  I re-based the implementation of Bundle.getHeaders() to be implemented using the OSGi API BundleWiring.findEntries which ultimately uses the class loader of the bundle if the bundle is resolved (and most all bundles better be resolved).  In most every case Bundle.getHeaders() is not the right API call to make since that will give you translated headers back.  In most cases only the raw untranslated headers are needed.  The Equinox weaving hooks was making calls to Bundle.getHeaders() for every bundle it tracked to find the supplemental information.  I change all these calls to Bundle.getHeaders("") passing an empty string.  This indicates that the raw headers are needed and will avoid a need for a class loader in order to find the translation resource for the bundle manifest.

On a clean (no cache) start you will still notice that Bundle.getHeaders() is called a lot by the extension registry.  This is because it is looking up translation values for all the plugin.xml files it is parsing and caching.  On a restart (from cache) the amount of calls to Bundle.getHeaders should be at a minimum.

If this proves to be an issue moving forward we can consider trying to get BundleWiring.findEntries not to aggressively create a class loader.  But this is the kind of complication I am really trying to avoid in the new implementation since it is much more simple to keep all the searching of resources from hosts+fragments in one spot (the class loader).

>
> - 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?


Is this a new issue found running on the new framework?  It seems like this would have been an issue on the old framework also.

>
> 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?


All the bundles involved in weaving need to start at start-level 1, along with simple configurator I would think.  Otherwise the DS implementation is likely to kick in and start loading classes for the components that are getting activated.

>
> Cheers,
> -Martin
>
>
> 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?

Yes, this is true.  Ever since we moved to git the workflow does not import the projects directly into the workspace folder.  Instead the code stays in the place where you cloned the git repositories.  Since weaving is in rt.equinox.bundles and org.eclipse.osgi is in rt.equinox.framework repo, the weaving.hook framework extension bundle is no longer co-located with the org.eclipse.osgi project on disk.  This means you must fully qualify the location of the extension bundle in order for it to work.  I need do an overhaul of the equinox adaptor hooks wiki [1].  But in the mean time perhaps you could update the wiki with a note about the setup for selfhosting here?


[1] http://wiki.eclipse.org/Adaptor_Hooks


Back to the top