Felix Meschberger <[EMAIL PROTECTED]> writes: > The issue I stumbled upon is the question of how to get at the > configuration to be provided to components. There are two ways to > get these: (1) call ConfigurationAdmin.getConfiguration(String pid) > and (2) register a ManagedService and have its updated(Dictionary) > method called
There is a third way: ConfigurationAdmin.listConfigurations(), with a filter looking like "(service.pid=...)". But even then, I think option 2 -- registering a ManagedService or ManagedServiceFactory -- is the only way for DS to comply with the tracking/updating requirement in Section 112.7: SCR must track changes in the Configuration objects used in the component properties of a component configuration. If a Configuration object that is related to a component configuration changes, then SCR must deactivate that component configuration and, if the Configuration object was not deleted, SCR must attempt to reactive the component configuration with the updated component properties. One tricky point from earlier in that same Section: SCR must obtain the Configuration objects from the Configuration Admin service using the Bundle Context of the bundle containing the component. I think this means that SCR has to register its ManagedService and ManagedServiceFactory services using the BundleContext of the component in order for the location binding aspect of Configurations¹ to work properly. > (I assume the ManagedFactory situation is comparable, hence I ignore > it for now). Yes, it's similar, swapping getConfiguration() for createFactoryConfiguration(), "(service.pid=...)" for "(service.factoryPid=...)", and updated(Dictionary) for updated(String, Dictionary). > The problem with the second method is, that the configuration update > must be executed asynchronously. Your ManagedService and ManagedServiceFactory implementations are allowed to synchronize their updated() methods, and the specification advocates synchronizing the registration to the same lock. From Section 104.15.9.1: The Configuration Admin service must call this method asynchronously which initiated the callback. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (Surely this is an error.) This implies that implementors of Managed Service can be assured that the callback will not take place during registration when they execute the registration in a synchronized method. And from Section 104.15.10.3: The Configuration Admin service must call this method asynchronously. This implies that implementors of the ManagedServiceFactory class can be assured that the callback will not take place during registration when they execute the registration in a synchronized method. Footnotes: ¹ Compendium Section 104.4.1, Location Binding. -- Steven E. Harris
