What you are asking for is not supported by the DS spec. A goal of the DS 
spec was to allow a POJO programming style and avoid/minimize OSGi api 
usage. So the DS design "hides" ConfigAdmin from the component by passing 
it as component properties. And when it changes, the component is 
reactivated.

In order to do what you want, there would need to be another API (a 
companion to activate and deactivate) such updatedProperties which advised 
the component of a new set of component properties. The component would 
also need to describe that it is interested in getting updated properties 
via this method instead of reactivation.

But, as I said above, this capability is not in the current DS spec not in 
the proposed changes for 4.2.
-- 

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:
"Fredrik Alströmer" <[EMAIL PROTECTED]>
To:
"OSGi Developer Mail List" <[email protected]>
Date:
2008/08/13 05:42 AM
Subject:
[osgi-dev] Declarative Services and Configuration Admin Service



Hi people,

according the OSGi Service Platform Service Compendium R4, 4.1, the
Declarative Services will interact with the Configuration Admin
Service and, if there's an update of the configuration with the same
PID as the service id, the component will be deactivated and
reactivated with the new configuration properties. What I haven't been
able to figure out though, is there a way to disable this behavior and
let the component listen for configuration changes itself during
run-time (it's obviously possible to define a separate PID, but that
wouldn't be passed to the component at activation, and it wouldn't be
possible to put the defaults in the component xml, I assume, which
would be a shame).

What I want to do is either use a managed service, or a configuration
listener (which I suppose is more or less the same for this purpose,
although a managed service would be more convenient, as it could be
managed by the declarative services), and get configuration updates
without having to reactivate the component, yet still get the current
configuration through the component context when the component is
activated. Is this possible somehow? Or did I miss something blatantly
obvious perhaps?

Thanks,
Fredrik.
_______________________________________________
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

Reply via email to