Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sisu-dev] Question about NexusBundleTracker

Hi Jonathan,

The extender code in Sisu has evolved from being a basic example of how to wire Guice-based bundles together into something more flexible (thanks to Gian’s contributions).

I wanted to verify that flexibility by taking the basic extender and enhancing it in Nexus to respect a bundle’s dependencies when deciding activation order. I’m now using that experience to improve the Sisu extender along similar lines. The main reason for the prepareDependencies method in Nexus was legacy assumptions in the code, but there is also a case for using it when you want to inject an implementation directly and not a proxy (because the implementation needs to be available and ready at the injection time).

So to answer your question: I am planning to bring those improvements back to the Sisu extender, including some form of prepareDependencies - but using this feature will be optional, as it isn’t required in all use-cases. With proxies and dynamic collections there isn’t such a hard requirement on activation ordering because they support lazy lookup.

-- 
Cheers, Stuart

PS, Sisu is OSGi aware in that it knows about bundles, their class spaces, and can blend per-bundle injectors into a consistent source of components and bindings.

On Monday, 17 November 2014 at 19:48, Jonathan Doklovic wrote:

Hi,

I've been looking at Nexus as a reference for my own app and I have a
quick question about the NexusBundleTracker class.

It has a prepareDependencies method which seems to blow through all of
the current bundle's dependencies and make sure they are all active (and
ultimately wired by sisu) before wiring the current bundle.

We have some legacy proprietary code that does essentially the same
thing that I was hoping to get rid of. I guess my question is why does
nexus have to do this? Is it because Sisu isn't OSGi aware and so nexus
needs to make sure all the stuff is available before letting Sisu try to
wire stuff? Seems like *everyone* that's going to use Sisu in an OSGi
container would need to do this, correct?

Thanks,

- Jonathan


Back to the top