[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Class visibility without declared dependency
- From: "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
- Date: Sat, 20 Jul 2013 17:24:56 -0400
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
On 7/20/13 16:33 , Stephan Herrmann wrote:
On 07/20/2013 09:43 PM, Richard S. Hall wrote:
On 7/20/13 10:46 , Stephan Herrmann wrote:
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
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.
If you manipulate some bundle's code and that code ends up with a
dependency on some other external code, you might as well accept
the fact that it does become a true run-time dependency (i.e., a
dynamic import) of the manipulated bundle. It doesn't make sense to
pretend that it isn't a dependency just because the dependency was
introduced at run time. The framework has to handle it like any
I see your point, but it still is an incompatible change.
With our weaver on top of the old adaptor hooks an aspect bundle
does not have to declare this dependency.
I didn't even mention that we have an additional mechanism
called "forced-export", which allows an aspect to bind to
a non-exported class. That mechanism requires to add exports
at load-time. It's a pretty big hammer and fortunately rarely
needed, but I've seen situations where it rescued a project.
Now that sounds scary. :-)
If you want to avoid that other bundles import the package in
question without knowing that they shouldn't, then just introduce a
mandatory attribute on the exported package.
What is "mandatory"? Do you mean x-friends?
I don't know anything about x-friends, since it is not spec and I'm not
really an Equinox guy, but a mandatory directive allows you specify that
some attribute on an exported package must be matched by the importer
otherwise no wire can be created. Normally, an importer only needs to
specify a package name at a minimum to match an exported package. With
the mandatory directive you can make exported packages behave more like
an "opt-in" model.
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?
In OSGi, the atomic unit of dependencies is the package, there is no
other way. The only wiggle room is with the include/exclude
directives on an export, but that isn't exactly the same.
I know that a manifest cannot import/export individual classes,
but a class loader hook can.
Currently, Object Teams can not run on the Luna framework and
for me this is a quite scary situation. Noticing my panic,
Tom had specifically invited me to ask on this list for help
how I can migrate the existing implementation of OT/Equinox
from the old adaptor hooks to the new framework.
From your answer I basically read we should have never done
what we did. That wasn't exactly my question :)
Well, you didn't have any other options before these spec'd hooks were
defined, so you did what you had to do. I wasn't offering a critique of
your original approach, I was just trying to allay your concerns about
modeling these things as real [dynamic] imports/exports since they
really are dependencies.
Any other ideas?
Not really. It sounds like you have read the weaving hook spec [which is
the first step], but you are concerned that it exposes previously
implicit dependencies as explicit dependencies. My advice is to accept
that they are real dependencies and move past that. Then the real
question is can you achieve what you need to do with the weaving hooks
equinox-dev mailing list