> From: Martin Lippert <lipp...@acm.org>
> 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
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
