Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sisu-dev] [SpamSentinel] Re: EntryListAdapter and notifications

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.

Back to the top