On Sep 18, 2009, at 10:56 PM, John Arthorne wrote:
> I implemented this by adding a context-id property when registering
> the event service. To consume a particular service, the context-id
> must be known, and the request is made by using a filter that includes
> the context-id property.
I tried an approach like this, with the p2 agent "location" as the context property. The problem I found was in lazy activation of services as needed. There was no way that I could find to declaratively register a service in a way that the "context" could be fed into the service when it was initialized. I suppose in your case the services are registered in eagerly activated bundles.
Yes, I started with eagerly activated bundle that started the first default context. I have instead tried an approach where rather than registering the services directly (engine, director, repository manager, etc), I register a factory as a service (engine factory, director factory, etc). This allows me to pass a context in at the time the service is created. Also, if it needs to obtain any other services when it starts it can grab them from this context. I mocked this up using Pascal's DI experiment bundle (org.eclipse.equinox.p2.di.experiment in the equinox incubator, and org.eclipse.equinox.p2.di.client as an example client bundle). I think this satisfies all our requirements (modular, lazy, dynamic, extensible) and the code for clients is still relatively clean. Feel free to check it out and provide comments here.
Sounds promising, I will try the same approach in b3.
|
