You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Agemo Cui <ag...@gamio.org> on 2009/06/02 00:00:01 UTC
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.
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
Re: 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.
Posted by Agemo Cui <ag...@gamio.org>.
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 <fm...@gmail.com>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
>
Re: 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.
Posted by Felix Meschberger <fm...@gmail.com>.
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