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
