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

[BJ Hargrave <hargrave@xxxxxxxxxx>]

> because services from lazy activated
bundles are available prior to being started

Technically that is not true. Services
from lazy activated bundles are available prior to being *activated* but
the bundle must have been started. That is, not in RESOLVED state; STARTING
or ACTIVE.

> Since the bundle providing the
extension is STARTED at this point, and all other lazy activated bundles
are STARTING

This sounds like a start ordering issue.
Since extensions are active in the RESOLVED state, the system will need
to be configured such that all bundles which will use extension to access
services are started before they will ever attempt to access the service.
--

BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargrave@xxxxxxxxxx

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

From:	John Arthorne <John_Arthorne@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	2009/09/17 10:17
Subject:	Re: [equinox-dev] Question about DI/ DS and Application model
Sent by:	equinox-dev-bounces@xxxxxxxxxxx

---

There is a mismatch, although use of DS brings the lifecycles closer together
because services from lazy activated bundles are available prior to being
started. I think the main problem here though is initializing executable
extensions after they have been instantiated to provide them with the services
they need. Since the bundle providing the extension is STARTED at this
point, and all other lazy activated bundles are STARTING (and hence their
services available to the SCR), I don't see the lifecycle difference causing
a problem (although it's quite possible I'm missing something as I'm still
relatively new to DS). 

John

BJ Hargrave <hargrave@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/16/2009 10:29 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Question about DI/ DS and Application model

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 hargrave@xxxxxxxxxx

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

From:	John Arthorne <John_Arthorne@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	2009/09/16 21:58
Subject:	Re: [equinox-dev] Question about DI/ DS and Application model
Sent by:	equinox-dev-bounces@xxxxxxxxxxx

---

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/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/16/2009 04:00 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev