Hi Clement, Thanks for the clarification. I assume, that to comply with the spec I would have to decide whether to register a ManagedService or a ManagedServiceFactory for a given component in the first place. This would probably be doable. The problem I have is with the asynchronicity: I register the service, I get updates, I have to re-register, wich in the case of a component means (according to the spec), deactivate and reactivate it, which seems somewhat overkill.
I could, as you say, register two services with the same PID, one as a ManagedService[Factory] and the other the real service (if at all needed), where the ManagedService[Factory] would update the real service. Regards Felix On 3/12/07, Clement Escoffier <[EMAIL PROTECTED]> wrote:
Hello, I am not sure that it's compliant with the SCR specification (in fact, I am sure that it's not compliant), but I implement the config admin support in iPOJO as following : - (Public) Component factory exposes ManagedServiceFactory - Component Instance can be created (and deleted) by using the ManagedServiceFactory - Component Instance does not directly exposed ManagedService. Indeed, the exposed pid and the pid who create the instance are the same, and the config admin does not suport this case. The reconfiguration of the instance must use the ManagedServiceFactory, but as you mentioned this update is called asynchronously. The problem of this strategy in iPOJO is that instances created by private factories are not configurable. An extension of this way could be : if an instance want to be configurable, and the ManagedServiceFactory is not exposed (private factory), the instance can exposes ManagedService. I don't implement this extension because it seems to be difficult to understand (and to use). Clement Felix Meschberger a écrit : > Hi all, > > I am currently integrating support for Configuration Admin Service > into the > Felix Declarative Service implementation (o.a.f.scr). This includes > providing the configuration from Configuration Admin to the component. > > 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 (I > assume the > ManagedFactory situation is comparable, hence I ignore it for now). > > The problem with the first method is, that the ConfigurationPlugins > are not > called (I interpret this from the sentence "If a bundle needs to force a > Configuration plugin service to be called again, it must fetch the > appropriate Configuration object from the Configuration Admin Service and > call the update() method (the no parameter version) on this object" in > Section 104.9.4, Forcing a Callback). The problem with the second > method is, > that the configuration update must be executed asynchronously. > > What shall I do in the SCR ? Should I ignore the Configuration Plugin > services and use the "simple" getConfiguration method or do I have to > support this (nasty) asynchronous situation ? > > What is the intention of the Specification here ? > > Thanks alot for any clarifications. > > Regards > Felix > -- Clement Escoffier Grenoble University LSR - Bat. C 220, Rue de la Chimie BP 53 38041 GRENOBLE CEDEX 9 04.76.51.40.24 http://clement.plop-plop.net
