Isn't there a big problem with the life cycle mismatch between services 
and extensions? Services require a bundle to be started. Extensions 
require a bundle to be resolved.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
John Arthorne <john_artho...@ca.ibm.com>
To:
Equinox development mailing list <equinox-dev@eclipse.org>
Date:
2009/09/16 21:58
Subject:
Re: [equinox-dev] Question about DI/ DS and Application model
Sent by:
equinox-dev-boun...@eclipse.org




Eventually someone has to decide which implementation of 
IMetadataRepositoryManager is going to be used. I think in the case of an 
application it is quite reasonable for the application to make this 
decision directly (by looking up the service, perhaps with some filter 
that helps to select the manager to use). By moving the lookup of 
IMetadataRepositoryManager into a DS component it just hides the fact that 
it is a simple service lookup and doesn't seem to offer any advantage. 

I think because both the service declaration, the implementation, and the 
client are all in the same bundle it's not a particularly interesting 
case. However I could imagine in more complex cases something like your 
solution 3 would be interesting. An executable extension factory could 
allow the services required by an executable extension to be injected into 
it rather than having the extension reach out. 

You'll see another package "solution3" in the bundle where I was playing 
around with another approach. I'm not sure it's any better than your 
solution 1 but you can take a look. 

John 



Pascal Rapicault/Ottawa/i...@ibmca 
Sent by: equinox-dev-boun...@eclipse.org 
09/16/2009 04:00 PM 

Please respond to
Equinox development mailing list <equinox-dev@eclipse.org>


To
Equinox development mailing list <equinox-dev@eclipse.org> 
cc

Subject
[equinox-dev] Question about DI/ DS and Application model








Today I have done some more DI exploration using DS to see how it fits 
with the constructs we have in eclipse and I'm struggling to integrate in 
a nice way with the application model (I mean without using static) and 
I'm looking to know how others are doing this?
The one line summary of my experiment is: I have a class that does some 
work (named RepositoryDumper), it needs a service (RepoMgr). I want now to 
create an eclipse application that invokes the RepositoryDumper and I 
would like to not have to acquire the RepoMgr service manually.

Here is what I have been exploring with:
Solution 1:
I have an application declared in the plugin.xml. I have created a DS 
component that instantiates RepositoryDumper. However the question now is 
how does the application (remember that an eclipse application extension 
needs to provides n class) can get a hold of the RepositoryDumper instance 
that got created by DS:
- 1.1: Ugly -> Store the instance RepositoryDumper in the Activator of the 
plug-in
- 1.2: Get the RepositoryDumper be registered as a Service and have the 
application get this service. I don't like this because now 
RepositoryDumper is visible to everybody just so I can get access to it

Solution 2:
This solution assumes that the declarative approach to the eclipse 
application model is the hindrance and works around it by registering an 
ApplicationDescriptor (org.osgi.service.application). To do so I create a 
DS component that instantiates the RepositoryDumper and also register an 
ApplicationDescriptor as a service. This has the nice attribute that 
everything gets injected and that the application is only available to run 
if all the necessary pieces are available. However it requires a lot of 
code since one has to implement ApplicationDescriptor and 
ApplicationHandle, and I don't think this application would even be 
launchable using the -application argument.

Solution 3:
This solution is an hybrid between 1 and 2 using the 
IExecutableExtensionFactory. 
There is a DS component that creates the RepositoryDumper and register a 
service, let's call it X. Then let's make the class specified in 
application extension (in the plugin.xml) implements 
IExecutableExtensionFactory and have it get the service X. This solution 
allows to have the application construction be completely done by 
injection however given that the application is contributed through 
extension registry it still is visible even though not ready to run.

How are others doing this? Is this a real problem or is it just me? Should 
I just not worry about that and use static fields?
Btw, the code is available /cvsroot/rt 
org.eclipse.equinox/incubator/p2/bundles/org.eclipse.equinox.p2.diagnostic 
Only solution 1 and 2 are available.

Thx for your attention and feedback

PaScaL_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Reply via email to