Re: [p2-dev] p2, dependency injection exploration

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

> 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