[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] IWeavingServiceFactory.createWeavingService takes a BundleDescription
- From: Martin Lippert <lippert@xxxxxxx>
- Date: Mon, 18 Mar 2013 16:15:47 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
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).
I am totally fine with the way it works at the moment and I also like
the design to keep all the searching of resources in one place.
> - 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.
Yes, this was an issue with the old framework as well. I just came
across this again and that reminded my to ask you for ideas for a better
> 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.
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.
Ok, sounds good to me.
Regarding the new OSGi weaving hook: I read this is a simple OSGi
service that also needs to be started early on. So the same rule applies
here, right? Or is there other machinery in place to allow this OSGi
weaving service to be in place earlier?
> 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 . But in the mean time perhaps you could update the wiki
with a note about the setup for selfhosting here?
equinox-dev mailing list