This is nice exploration Brian. I'll just reiterate my suggestion from the call to keep any pluggable lookup strategy internal for the current release. I suspect it would be fairly easy to build something to suit your needs, but there are going to problems generalizing it. For example, can there be multiple strategies plugged in, what is their order of precedence, how do they notify the context of changes, etc.
John From: Brian de Alwis <[email protected]> To: E4 Project developer mailing list <[email protected]>, Date: 02/27/2013 12:31 PM Subject: [e4-dev] API / Implementation feedback on contexts Sent by: [email protected] I've been doing some investigatory work into how to bridge an existing services system (with thousands of services) into our IEclipseContext setup. We're dealing with potentially hundreds of such services. Here's a few things I've discovered: The ILookupStrategy that was backed out as a result of bug 317706 would have been really useful. In my case, I want to hook these services into the part/window/app level contexts. I can't create my own IEC subclass as I don't have the opportunity to replace the class used to create child contexts. I mentioned this on the E4 call last week and have opened bug 401931 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=401931). IContextFunction#compute() should receive the requested context key. We explored using IContextFunctions to look up our services, but it required creating an ICF for each service which is a bit expensive. I've filed this as bug 401933 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=401933). For now I've instead implemented my own object supplier, which is pretty cool. Two notes from here (and they're just documentation issues): It's not clear how ExtendedObjectSuppliers can hook into the group-changes: although an EOS could assume that the primary object supplier is a ContextObjectSupplier and request to be injected with an IEclipseContext, the EclipseContext addWaiting()/processWaiting() is internal to contexts. This only becomes an issue if we have methods that mix custom injections and normal context injections. And perhaps this is asking a lot anyways! I was a bit surprised that disposing of a context doesn't uninject the fields, and so my EOS's get() wasn't called with track=false. Rather, the IRequestor.isValid() will return false once the injected object is GC'd. I saw injections continuing on my disposed objects as my objects were being held onto… by my EOS! (Inadvertent, and now fixed.) BTW: The one gotcha to implementing a custom object supplier (any component for Declarative Services): ensure your bundle is lazily-activated as DS otherwise ignores the service components until that bundle is explicitly started. Brian._______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
