[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Class visibility without declared dependency
- From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
- Date: Mon, 22 Jul 2013 23:55:28 +0200
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
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?
BTW: My first tests are actually up-and-running on the new hook
already. Now only come the second 80% :)