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. 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. 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). 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. 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. Thanks, Agemo
