Hi Craig,
Sorry to only be able to follow up on this now (I was as Richard said
ways for vacation).
So here is, what you are looking for:
Felix SCR registers a ManagedService[Factory] for each declared
Component[Factory] with the service.pid property set to the component
name. This ManagedService[Factory] receives configuration updates from
the ConfigurationAdmin on behalf of the component and forwards the
configuration to the component appropriately:
- Components are deactivated and activated
- ComponentFactory have their newInstance method called
(or delete method if a Configuration was deleted)
This is what the spec on Declarative Services says should be done by the
implementation. The spec also says, that components should not (or is it
must not ?) register a ManagedService[Factory] service themselves --
because the Declarative Services implementation is providing the
configuration.
The spec also sais, how the Dictionary returned by
ComponentContext.getProperties() must be filled: with the component
declaration properties overlaid with the properties from the
Configuration Admin (if any).
In short: your component does not have to care about getting the
configuration from the Configuration Admin. It is provided by the
Declarative Services implementation in the ComponentContext given to the
activate method.
This works quite well and in fact Apache Sling heavily relies on this
functionality.
Hope this helps.
Regards
Felix
Craig Phillips schrieb:
Hi, good morning,
Maybe someone out there knows or has an idea of how configuration is
supposed to work within the context of declarative services and could
give me a one paragraph blurb and point me in the right direction...
I attempted to set up my bundle to provide the ManagedService and an
implementation of "updated(Dictionary)" thereof... My updated() method
was invoked twice with a null argument for Dictionary, even though I
provided a sample property key/value in the OSGI-INF entry;
If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
configuration property, I get the infamous "configuration already sent"
nag...
If I use a file based property a la the file persistence manager, I get
the same "configuration already sent" nag...
I then proceeded to obtain the ConfigurationAdmin service handle and
invoke the "update(Dictionary" method... besides hanging for quite some
time (I literally have to go to the TUI shell is issue a command like
"ps" or something to that effect to break the hang -- I have a number of
issues with TUI causing various functionality to hang, specifically
listen sockets);
I'm about to ditch declarative services and see if I can manually set
all this up... I figure that probably will work... I'm fairly certain
it's the SCR that's conflicting somehow... and, I suspect, if I get
around to reading those pages in the compendium spec, it'll probably be
my own ignorance somehow -- meaning, the SCR has somehow or another
wrapped up all the boiler plate and the end user is supposed to register
a setter method or something...
If someone out there has "felt my pain" and can steer me in the right
direction, much appreciated,
Thanks, Craig Phillips, Praxis
