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. In you previous approach your equinox specific hook would intercept a class load request and side step the framework without the framework knowing or understanding what is being done. This can lead to inconsistent class spaces or stale references to old class loaders. 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. 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). Tom From: Stephan Herrmann <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 07/20/2013 09:46 AM Subject: [equinox-dev] Class visibility without declared dependency Sent by: [email protected] Hi, In the old framework I could use the ClassLoaderDelegateHook to make aspect classes visible to those base classes into which I'm weaving calls to the aspect. This is necessary, because only the aspect knows about its base, not vice versa. For Luna with the new WeavingHook all I can see is wovenClass.getDynamicImports().add(somePackage) This does, however, not work for packages that are not exported from the aspect bundle. In fact most of the aspects are never exported, because they're not meant to be called from source code. Additionally, in the old hook I had the option to expose individual classes, not packages. I didn't yet use this power, but to enforce that the synthetic dependency is indeed only ever used for the synthetic aspect calls this would be valuable in the future. So if a class-based mechanism is available I'd always prefer that over a package based mechanism. Any ideas how I could make this work in the new framework? Thinking more about it, in the future I _could_ request that aspects actually declare the corresponding base as x-friends, but (a) this is redundant information, easy to run out-of-sync, and (b) it would be an incompatible change, and (c) I don't know how the runtime could detect when a package added to dynamic imports is *not* exported. Thus, if there's any way around this, I certainly prefer *not* to require such x-friends export at source level. If that could be added on-the-fly this might be another viable solution. thanks, Stephan _______________________________________________ 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
