[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [sisu-dev] [SpamSentinel] Re: EntryListAdapter and notifications
|
On Wednesday, 3 December 2014 at 14:55, gian.maria.romanato@xxxxxxxxxxxx wrote:
Hi Stuart,
sisu-dev-bounces@xxxxxxxxxxx wrote on 21/11/2014 17:16:20:
> One way to decouple this further might be to support a limited form
> of JavaEE’s @Observes annotation, backed by the mediator pattern:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=452675
>
> @Observes is part of CDI, which is the enterprise extension to JSR-330
If I am not mistaken, Sisu already uses a bit of reflection
to support the CDI Priority annotation besides its own org.eclipse.sisu.Priority
annotation.
Correct, and support for @Observes is likely to be done in similar fashion
I'd love to help out on both this topic and the contextual
injection feature I asked you about a while back. This is not currently
possible for me, I hope to be able to contribute in the near future.
Meanwhile, I have another question for you :-)
I am using 0.2.1 and I have been using injected lists
for some time. As I probably already told you, my OSGi application also
uses the Equinox registry. There is some overlap in what you can do with
the Equinox registry and with dependency injection, and now that Sisu is
available, for new developments I generally prefer dependency injection
over the Equinox registry whenever possible, because implementation is
faster, it's simpler to test, and does not require to deal with the Equinox
registry API that is DOM oriented and looks very much old-school these
days.
And by the way, before knowing of the mediator, I
was also using the Equinox registry when I wanted to receive notifications,
as the Equinox registry provides two interfaces you can implement to get
notified about extensions as they come and go with their respective declaring
bundles.
Few days ago I was using an injected list and I wrote
a test case using TinyBundles to programmatically create an OSGi bundle
that contained a Guice module which bound an additional implementation
of the interface type I was getting injected as a list.
In my test, I found out that I must consume all the
list (via iterator) for the list to realize that another object has arrived.
In other words, the list does not know of the new
implementation bound by the programmatically created OSGi bundle, till
I iterate over it once. After I have iterated over the list, the next time
I iterate over the list again the new item is there.
Is this the intended behaviour? Could you elaborate
a bit about how those dynamic lists work?
This is the intended behaviour, the underlying iterable is lazy on purpose and keeps track of where it is wrt. new bindings coming in (which may have different priority)
This is to support mixing fast sources of bindings with slower ones (such as an external registry) while supporting mixed binding priorities.
I’ll write up the design on the wiki rather than continue here, mainly because it deserves some diagrams but also because others may be interested in how it works.
Because I originally though that
this behaviour could be due to the fact that the object containing the
injected list had been instantiated before installing and starting the
OSGi bundle created via TinyBundles, but if I am not mistaken, this is
not the case and even if I instantiate the outer object after activating
the test bundle, I still need to consume the whole list once, before the
new implementation shows up in the list.
Not quite: if you have an iterator ITR which you’ve iterated to a particular point (say you’ve just seen component A) and something adds component B to the system then you won’t see B when you continue to iterate on ITR if component B has a priority higher than component A. This is to preserve consistency in ranking components, because the next time you iterate over the collection (using ITR2) component B would appear before component A in the ordering (as higher priority components appear first).
However, if you use the List API then while that’s backed by the same iterable, each operation uses a new iterator instance which will see any new component - so you shouldn’t need to iterate over the entire list before “contains”, etc. will work.
If that’s not what you see then a recreatable project/testcase would be useful.
Is this the expected behaviour or maybe an issue I
introduced in my custom extender?
Thanks
GianMaria.
_______________________________________________
sisu-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
