> From: Martin Lippert <[email protected]>
> 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_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
