Re: [sisu-dev] [Bug 403108] Support sharing of AOP method interceptors b

[gian.maria.romanato@xxxxxxxxxxxx]

> BTW, you might be interested in https://bugs.eclipse.org/bugs/
> show_bug.cgi?id=386434 which will look into integration of extension
> points into Sisu (work on this will start soon)

Thanks, I added myself to CC since 0.1.0 :-)

[about of type listeners]

> above one technique could be to register a generic
type listener (by
> adapting the example extender code) and then use that to defer 
> lookup of the actual type listeners to the extension or service 
> registry.

That's certainly an option, but I am starting to believe
that as you said
there is not a single solution to the problem.

Also, one of the reasons I like Sisu so much is because
it makes my code portable 
between OSGi and JSE. So if I had to implement your
suggestion, I would 
go for the equinox registry to preserve portability.

> I still lean towards sharing modules via the extender/fragment 
> pattern just because it self-documents the ordering/dependency.

[...cut...]

> >> We could consider recording any @Named module classes in
the injector (in
> >> addition to installing them) which would let you query them
via 
> the locator.
> >> The sample extender still wouldn’t automatically share modules
across
> >> bundles, but you could use this information in your own custom
extender to
> >> share modules that had a specific marker interface or marker
annotation.
> >> 
> >> Logged as https://bugs.eclipse.org/bugs/show_bug.cgi?id=426197
> > 

In short, my point is that given that the whole purpose
of Dependency Injection is to 
reduce coupling, I find it a bit strange that to reuse
bindings from a shared module 
a bundle must list such module in its own META-INF/services/*.Module
file. 
It's probably just a philosophical issue, but this
approach requires at least knowledge of 
the shared module (e.g. class name) and that looks
like a sort of coupling to me, 
and it smells a bit fishy. 

In any case, your suggestion of tagging shared modules to let the extender
bind them in any other extended bundle sounds reasonable
and might be a good option
for my custom extender.
 
> Any previously extended bundle will be subscribing to various types
> (they implicitly subscribe as they call the locate/watch methods of
> the BeanLocator) and as other extended bundles come and go they will
> notify these subscribers - which then update the associated 
> component collections, notify mediators, etc. This is how Sisu 
> supports dynamic component collections without requiring polling or
> back-references to the locator.

Looks good but I am worried this may be too complex
and/or not worth the effort.
If I accept the limitation that shared modules will
be usable only by bundles
started after the declaring bundle, I can apply your
previous suggestion about tagging modules,
which seems reasonably easy to implement and to understand
without requiring 
a deep knowledge of Sisu internals, and which represents
a good trade off
between functionality and complexity.

Thank you.