This feels like a friend of the "when are all the services available"
problem. There may be some things that can be done with particular DS
implementations to see what components/services have been discovered
but not yet made real.
This does not however help with bundles that are not yet started or
installed. If you want to know when your system has "settled" on a
bundle level you have to define what that means for you (since there
is no such notion in OSGi). For example, you can listen for bundle
events and if none has arrived for N <timeunits> then you are ready to
go. "de-bouncing" per se. Start levels could help but don't
guarantee that no new bundles will arrive.
Jeff
On 2009-11-13, at 10:25 AM, David Bosschaert wrote:
Hi all,
Thanks for the feedback. Sorry that I didn't formulate my question
precise enough.
I got things working with a separate class that implements the
ManagedService which only gets used if the class is there available
(optional cm import).
The main question I'm still a little struggeling with is: how long
do I wait. As Per says, if the CA service is present I will get
called with updated() no matter what. But how long do I wait before
deciding that the CA service is not present? Especially during
startup this could depend on the bundle ordering and considering the
machine capabilities and the number of bundles this could take
either a long time or a fairly short amount of time. I'm not
particularly a fan of arbitrary timeouts so I was thinking is there
some other mechanism? I also don't want to use the defaults if
typically in the next second the real values become available...
Maybe something like this:
* every second look at all the installed bundles
(BundleContext.getBundles())
* if this information doesn't change (no extra bundles and all the
bundles remain in their previous state) assume that the system has
started up
* now check whether the CA service is there, if not use the
defaults...
Or would using the StartLevel service be an alternative? Or does
that merely move the problem?
David
Per Gustafson wrote:
I think the general approach BJ describes is good. But in case (2)
the MS will get called with a null dictionary (see 104.5.3 of the
Compendium spec) so you don't have to bother with a timeout.
/Per
On Nov 13, 2009, at 08:36 AM, BJ Hargrave wrote:
I think your question is: How long do I wait for my ManagedService
to be called with my configuration before I decide I need to use
some defaults?
There are 2 reasons why your MS may not get called. (1) There is
no ConfigAdmin running (yet). (2) Your MS does not have a
configuration.
(1) Can be detected because there is no ConfigAdmin service
registered. If this is the case, use your defaults but still
register the MS because the ConfigAdmin service may get started
shortly.
(2) If there is a ConfigAdmin service, then you may want some
timeout before you give up waiting for some configuration and
using your defaults. In this case still leave your MS registered.
In all cases, register the MS and respond to update.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
David Bosschaert <[email protected]>
To:
OSGi Developer Mail List <[email protected]>
Date:
2009/11/12 23:22
Subject:
[osgi-dev] How to reliably detect that Configuration Admin is
*not* present?
Sent by:
[email protected]
Hi all,
I have a bundle that can be configured through Configuration Admin.
However when CA is *not* present it can still function using default
behaviour.
Question 1: What would be the best way to let it check that the
Configuration Admin service is not present, so that it can proceed
with
its default behaviour?
Question 2: I would really like it to have an *optional*
dependency on
org.osgi.service.cm. but still my code provides a class that
implements
org.osgi.service.cm.ManagedService I guess this should be possible,
right? I was thinking of the following algorithm:
If Not Config Admin Present then
default behaviour
else
register MyManagedService // only at this point the ManagedService
class gets loaded
... handle configuration as soon as updated() gets called.
Is this a feasible approach?
Thanks,
David
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
