I'm agree with Marcel.
We need to keep in mind that OSGi is very dynamic: developers have to
work with this state and consider that things can't be present when
required.
Regards
JB
Marcel Offermans wrote:
I think some of the solutions here are overcomplicating things a lot.
OSGi is a dynamic framework. Things can go away or change at any point
in time, so just deal with that. If your service can run without
configuration, then start with defaults. If not, wait until you get a
configuration.
Greetings, Marcel
On Nov 13, 2009, at 17:52 , David Bosschaert wrote:
Hi all,
Thanks for all the thoughts. What BJ has proposed looks like an
interesting approach to me. I understand that it's not a 100% safe but
I guess I'm just trying to cater for the common case. If the more
esoteric cases (the ones from Tom) aren't covered they should still
work and I think in those cases a quick flip between defaults and
actual values wouldn't be the end of the world.
I'll experiment a bit and see how things go.
Thanks!
David
Thomas Watson wrote:
There is a snag with this approach. Imagine your bundle and the CM
implementation has a start-level of 4 and that the framework is
launched with a beginning start-level of 3. At launch the system
bundle will be in the STARTING state until the start-level 3 has been
reached. At that point the FrameworkEvent STARTED will have been
fired and the system bundle will be ACTIVE. Later if someone raises
the start-level to 10 your bundle will be allowed to activate along
with the CM implementation but the order may be such that your bundle
is activated before the CM implementation.
During your bundle's activation the system bundle will be ACTIVE but
there will be no CM service available yet. You could try to listen
for the STARTLEVEL_CHANGED event, but you have no idea if your bundle
is being activated because of a start-level change or simply because
someone called start on your bundle. The other issue with this
approach is that there is no guarantee that the CM implementation
bundle will synchronously register its service during its activation.
Even after the FrameworkEvent (STARTED or STARTLEVEL_CHANGED) event
has been fired there may be some asynchronous operation going on that
will eventually cause the CM service implementation to be registered.
The only safe way I can see to do this is to always register your
ManagedService, if your ManagedService was not called with a
configuration (or null for no configuration) during the registration
of the ManagedService then you must apply your defaults. This may
introduce some quick churn between your defaults and an actual
configuration if the CM implementation is registered after you have
registered your ManagedService but I see no safe/elegant way around
that.
Tom
Inactive hide details for BJ Hargrave---11/13/2009 09:56:20 AM---If
you optionally import the cm package and don't "get it" wheBJ
Hargrave---11/13/2009 09:56:20 AM---If you optionally import the cm
package and don't "get it" when you resolve, then you will never see
CA, so just use the defaul
From:
BJ Hargrave/Austin/i...@ibmus
To:
OSGi Developer Mail List <[email protected]>
Date:
11/13/2009 09:56 AM
Subject:
Re: [osgi-dev] How to reliably detect that Configuration Admin is
*not* present?
------------------------------------------------------------------------
If you optionally import the cm package and don't "get it" when you
resolve, then you will never see CA, so just use the defaults.
If you get the cm package, register your MS. Then look to see of the
CA service is registered. If it is, then just wait for the call to
your MS. If the CA service is not registered, then immediately use
your default. Then later if CA is started, you will get called at
your MS and you can then move to use the configuration (if any).
If you get started before CA during framework launch, then you may
end up using your defaults for a brief period before you get called
at your MS. You can compensate for this by looking at the state of
the system bundle (during your activator). If the system bundle state
is STARTING, the framework is launching. Register a FrameworkListener
and wait for the STARTED event which tells you launch is complete. If
you haven't been called at your MS by then, then there is likely no
CA service.
--
*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
[email protected]_ <mailto:[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/13 10:29
Subject: Re: [osgi-dev] How to reliably detect that Configuration
Admin is *not* present?
Sent by: [email protected]
------------------------------------------------------------------------
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
------------------------------------------------------------------------
_______________________________________________
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
--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[email protected]
PGP : 17D4F086
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
