| Re: [equinox-dev] IWeavingServiceFactory.createWeavingService takes a BundleDescription |
> From: Martin Lippert <lippert@xxxxxxx>
> Hey Tom!
[stuff deleted]
> > 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.
OK, I will keep it for now. I did take a quick look and it may not be that hard to extract out this logic completely from the ModuleClassLoader since this is only used by the implementation of ModuleWiring. I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=403657 to discuss further.
[stuff deleted]
> > 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?
Correct the OSGi spec'ed WeavingHook services suffer from the same boot strap issues. The must be registered early before the rest of the system starts loading classes that you want to weave.
Tom