[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] p2, dependency injection exploration


> 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.

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.

John




Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

09/11/2009 07:16 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] p2, dependency injection exploration





Hi,
I have experimented with one part of this:


On Sep 10, 2009, at 4:08 PM, Pascal Rapicault wrote:

> 1) do I have one bus for my VM?
> In this case, the initial pattern of grabbing THE bus and listening  
> still works, though the events being broadcasted need to be more  
> specific as some listeners would probably get things they don't care  
> about.

I think it is best with one Bus per "p2 instance"

> 2) do I have one bus for each engine?
> In this case, how are the listeners registered? How would a bundle  
> interested in listening to a particular Engine know which bus to  
> listen on? How could it come after the fact?


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. Similar to p2, my use case has a default  
context instance expected to always be there, and there is a well  
known context-id defined for this. In my case, the context is itself a  
service, and I have one bundle that contains the set up of this  
default context.


Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev