I'm going to respond to these questions in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=406518
I think it would be better to record this discussion in a bug report for ObjectTeams. If others are interested they can CC themselves ;-) Tom From: Stephan Herrmann <[email protected]> To: [email protected], Date: 07/22/2013 04:56 PM Subject: Re: [equinox-dev] Class visibility without declared dependency Sent by: [email protected] Hi Tom, Thinking more about this, I kind-of want both, see below :) On 07/22/2013 02:59 PM, Thomas Watson wrote: > I see Richard Hall chimed in already. The important point to remember is that your weaving hook introduced a real runtime > dependency. There are two main reasons the standard weaving hooks use the concept of dynamic imports for wiring these additional > dependencies at runtime. > > 1) A consistent class space must be maintained. The OSGi resolver must be involved to ensure this is maintained. Dynamic imports > get resolved by the resolver which lets the framework maintain the consistent class space for each bundle. > 2) A publically visible wire allows for proper class loader clean up when refreshing bundles. When a woven bundle gets dynamically > wired to some package then its class loader is bound to the lifecycle of the providing class loader. If the providing class loader > gets refreshed then any class loader wired to it must also be refreshed so we can avoid stale references to old class loaders. Thanks. Makes sense. So, I'm starting to agree that class based manipulation of visibility is maybe one level too crafty. So let's assume I fully migrate to package level wiring, I still have the problem that I can only add imports, not exports. See below ... > If you would start over (with no worries about breaking compatibility) then I would recommend you require bundles to export any > package they want to be dynamically woven into bundles. As Richard suggests, you could use the mandatory directive to prevent > casual importers from getting wired to these packages. Also mentioned by Richard, you could use the include/exclude directives on > the package to filter on particular class names, but I find that generally overkill. ... maybe ... > But, if you are not willing to or able to break compatibility (believe me I understand) then you may be left with no choice but to > remain an equinox specific hook. For that I do think the new framework should still allow you to do what you need (although, it > still has all the issues I mention above). ... this one, I want, too! I sure see a point in moving towards full OSGi compliance. But I still want to provide the *option* to let exports be added dynamically, too. I'll add support in the IDE to warn if that is the case, to let users know whether their bundles can possibly run on other containers, or depend on Equinox specifics. Back to the question, how to achieve this on the new framework? I just now noticed that the ClassLoadingHook isn't completely gone, the current ClassLoaderHook looks a lot similar :), so I'll experiment with re-using some of my old code with that hook (ignoring the x-friends on o.e.o.internal.hookregistry for now). In Kepler I also use a StorageHook, but that hook has change a lot. Can it still be used for some kind of on-the-fly header re-writing? At the downside I'd still need a framework extension, if I use any of these hooks, right? Do you see a (Equinox specific) way how I could add exports at the package level, rather than fiddling with the ClassLoaderHook? thanks, Stephan BTW: My first tests are actually up-and-running on the new hook already. Now only come the second 80% :) _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
