Hi Steven, Thanks for the elaborate reply.
On 3/12/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
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:
Not really. Thanks to ConfigurationEvents, I can register as a ConfigurationEventListener an get informed on all configuration updates. In fact my current implementation implements such a listener and - on event - cycles the respective component. This works well. 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.
This is not really an issue, because all other works on declared components must have the BundleContext, too. So I use the component's BundleContext to get the ConfigurationAdmin service for that bundle. Thus I get correctly bound configurations.
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:
Yes, that is so. But: If I have a thread T1 which is activating a component C1. If C1 would be registered as a ManagedService, I would also provide Service properties, which are the declared properties of C1 without the Configuration Admin properties and I would activate C1 with the same properties. Configuration Admin would the update the ManagedService of C1 thus resulting in a requirement to deactivate C1 and reactivate C1 with the new properties, this time including the Configuration Admin properties. This results in the component being activated-deactivated-activated just for the sake of configuration, which seems overkill. And this does not even take into account any other components, which might depend on the first resulting in a storm of cyclings..... I might optimize by just registering a ManagedService and wait for the configuration update - but then, this will never come in case no Configuration Admin Service would be available, so I would have to check for this special case ... a nightmare. But back to question: What is the intent of the Spec: Should the components be provided with configuration which has undergone ConfigurationPlugin treatment or would it be acceptable to get "raw" configuration through ConfigurationAdmin.getConfiguration. Regards Felix 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
