Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4A24C366.6060203@gmail.com>
References: <48096aa50906011500i59d5ddc7u9109ae7561af02a2@mail.gmail.com>
	 <4A24C366.6060203@gmail.com>
Date: Tue, 2 Jun 2009 09:15:06 -0400
Message-ID: <48096aa50906020615w583b5535la2174c5b353e4d67@mail.gmail.com>
Subject: 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.
From: Agemo Cui <agemocui@gamio.org>
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=001485f46e80db3fc4046b5d5491

--001485f46e80db3fc4046b5d5491
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <fmeschbe@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
>

--001485f46e80db3fc4046b5d5491--