Thanks for your comments. Now I'm clear. And your solution is great.
Regards, Agemo On Tue, Jun 2, 2009 at 2:15 AM, Felix Meschberger <[email protected]>wrote: > Hi Agemo, > > Agemo Cui schrieb: > > If the component has a configuration in CM before it's enabled, then this > > component may be activated twice when enabled on the first time. > > > > The first time it's activated with the enablement without the > configuration > > from CM. > > The second time it's activated by receiving the configuration update from > > CM. > > Right. The current implementation is based on registering a > ManagedService[Factory] on behalf of the Component[Factory]. Thus the > SCR does not _ask_ for the configuration (or even wait for it) but just > activates the component and cycles it later when configuration arrives. > > > > > Though this behavior does not violate the spec, I think it's better to > get > > rid of the first time activation, the one without configuration. > > Because the configuration is already there before the component is > created, > > activating it without the configuration looks meaningless. > > True, but the current implementation does not allow this and I don't > want to introduce another mechanism for the "first start". > > We could of course change the mechanism completely: > ManagedService[Factory] services are not used anymore. Instead we > implement a ConfigurationListener to update components and use > ConfigurationAdmin.listConfiguration for first activation. > > > > > > > Actually, in the R4.2, the spec has a change about > "configuration-policy". > > The default value is "optional" which I think is the one compatible with > > R4.1. > > However the logic of "optional" is that when the component is going to be > > activated, it should consult CM to see if the configuration for it exists > or > > not. > > If the configuration exists, the activation of the component will use it, > > which looks kind of the same requirement as mine that is aforementioned. > > > > What I think is: Can we move "register the ManagedService" from the > > constructor of ImmediateComponentManager to AbstractComponentManager's > > enable method. > > And before registering it, we need consult CM to see if the configuration > > exists. If does, then we should enable the component without activation > and > > leave the activation to be done in reconfigure since the configuration > will > > be updated anyway. And sure, in the "reconfigure" there's no need to do a > > state check to do reactivate(call reactivate directly with the state > design > > pattern should work). > > In this light, it might really be better to drop the > ManagedService[Factrory] approach and move to the > ConfigurationListener/listConfiguration approach: > > * On activation of a component we use listConfiguration to check for > the configuration(s) (don't use getConfiguration, since this would > create them if non-existing and this is not what we want) > * To update active components we register a (single) > ConfigurationListener which dispatches configuration updates > (creations, modifications, updates) to the components. > > WDYT ? > > > Actually, I'm developing an open-source project that is using OSGi. And I > > choose Felix as the OSGi implementation. It uses Felix > framework(embeded), > > scr and configadmin as the kernel. > > Cool Stuff ! Your contributions are very welcome and I am happy you like > our implementations. > > > > > I really appreciate the documentation of felix. And each bundle is very > > convenient to be installed for it's just a single jar. I wish felix could > be > > the best. > > So do ;-) > > Regards > Felix >
