+1 -- give me the latest / greatest dictionary without re-activation; I am not emotionally attached to a specific mechanism to accomplish said 'requirement', be it listener or non-deactivate re-invocation of the DS/SCR activate() method, although my gut feeling is the consensus would prefer a listener type behavior; I'd be happy with just getting the latest/greatest dictionary and let me figure out the adds/deletes/mods, but a listener is good too...
________________________________
From: [EMAIL PROTECTED] on behalf of Peter Kriens
Sent: Wed 8/13/2008 5:45 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Declarative Services and Configuration Admin Service
I do not think this is possible with the current specification.
However, we are working on an update and we can still discuss this
requirement.
Would it solve your problem if you could implement a ManagedService
interface? If the DS then saw you implemented this interface it would
not deactivate you, but just give you the dictionary?
Kind regards,
Peter Kriens
On 13 aug 2008, at 11:28, Fredrik Alströmer wrote:
> 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
<<winmail.dat>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
