Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sisu-dev] [Bug 403108] Support sharing of AOP method interceptors between injectors

> 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.



Back to the top