Re: [sisu-dev] [SpamSentinel] Re: EntryListAdapter and notifications

[gian.maria.romanato@xxxxxxxxxxxx]

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. 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? 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.
Is this the expected behaviour or maybe an issue I
introduced in my custom extender?

Thanks
GianMaria.