You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2016/11/21 10:20:07 UTC
Ensuring that components have a configuration when started
Hi,
I think we have an ongoing problem with components that:
- are defined with ConfigurationPolicy.OPTIONAL
- have a configuration defined in the provisioning model
What can happen is that the component is activated, is referenced and
used, and at a later time is configured.
For an example of this see SLING-6305 [1], where the
LoginAdminWhitelist config is applied too late.
Top of my head, some (probably bad) ideas are:
1) Make the component require a configuration
This makes the component less flexible and we should aim for a minimal
configuration with Sling.
2) Post-process the configurations using the slingstart-maven-plugin
and adjust the configurationPolicy to be ConfigurationPolicy.REQUIRED
This is a bit suprising and makes it harder for components to be
switched to a default configuration after being provisioned.
Suggestions would be greatly appreciated :-)
Thanks,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-6305
Re: Ensuring that components have a configuration when started
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2016-11-21 at 10:25 +0000, Felix Meschberger wrote:
> Hi
>
> I suggest to attack the problem at the right place !
>
> When Configuration Admin is active and configuration is stored in
> Configuration Admin, then configuration *is* provided as soon as such
> components are activated. If not, this is an SCR bug.
>
> Now, I assume you have a provisioning problem in that the bundles are
> started and thus the components activated *before* the configuration
> is actually stored in Configuration Admin.
>
> If this is the case, then please fix the initial provisioing process
> and *not* the components.
Agreed, and I think that's what SLING-5779 does. And yes, I reported
it, but my bad memory prevented me from remembering that :-)
Robert
>
> Regards
> Felix
>
> > Am 21.11.2016 um 11:20 schrieb Robert Munteanu <ro...@apache.org>
> > :
> >
> > Hi,
> >
> > I think we have an ongoing problem with components that:
> >
> > - are defined with ConfigurationPolicy.OPTIONAL
> > - have a configuration defined in the provisioning model
> >
> > What can happen is that the component is activated, is referenced
> > and
> > used, and at a later time is configured.
> >
> > For an example of this see SLING-6305 [1], where the
> > LoginAdminWhitelist config is applied too late.
> >
> > Top of my head, some (probably bad) ideas are:
> >
> > 1) Make the component require a configuration
> >
> > This makes the component less flexible and we should aim for a
> > minimal
> > configuration with Sling.
> >
> > 2) Post-process the configurations using the slingstart-maven-
> > plugin
> > and adjust the configurationPolicy to be
> > ConfigurationPolicy.REQUIRED
> >
> > This is a bit suprising and makes it harder for components to be
> > switched to a default configuration after being provisioned.
> >
> > Suggestions would be greatly appreciated :-)
> >
> > Thanks,
> >
> > Robert
> >
> >
> > [1]: https://issues.apache.org/jira/browse/SLING-6305
>
>
Re: Ensuring that components have a configuration when started
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2016-11-21 at 14:14 +0100, Bertrand Delacretaz wrote:
> On Mon, Nov 21, 2016 at 11:25 AM, Felix Meschberger <fmeschbe@adobe.c
> om> wrote:
> > ...I assume you have a provisioning problem in that the bundles are
> > started and
> > thus the components activated *before* the configuration is
> > actually stored
>
> �in Configuration Admin....
>
> I also think configurations should be active very early in the Sling
> startup - if they are provided in the provisioning model they are
> available right from the start.
That's something which is not 100% clear to me - why are they not
available from the start. The configadmin and osgi installer bundles
are available early in the process, definitely before the repository is
up so the LoginAdministrativeWhitelist component should start with a
configuration available.
I think a hint is present in Carsten's comment from [1]
> the issue here is that the support for configurations is available
after the OSGi installer already started its work. The installer is
happily installing bundles and only once that is done completely it
picks up the configuration support which was registered while it was
installing the bundles
Robert
[1]: https://issues.apache.org/jira/browse/SLING-5779?focusedCommentId=
15329297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#comment-15329297
Re: Ensuring that components have a configuration when started
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Nov 21, 2016 at 11:25 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...I assume you have a provisioning problem in that the bundles are started and
> thus the components activated *before* the configuration is actually stored
in Configuration Admin....
I also think configurations should be active very early in the Sling
startup - if they are provided in the provisioning model they are
available right from the start.
-Bertrand
Re: Ensuring that components have a configuration when started
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
I suggest to attack the problem at the right place !
When Configuration Admin is active and configuration is stored in Configuration Admin, then configuration *is* provided as soon as such components are activated. If not, this is an SCR bug.
Now, I assume you have a provisioning problem in that the bundles are started and thus the components activated *before* the configuration is actually stored in Configuration Admin.
If this is the case, then please fix the initial provisioing process and *not* the components.
Regards
Felix
> Am 21.11.2016 um 11:20 schrieb Robert Munteanu <ro...@apache.org>:
>
> Hi,
>
> I think we have an ongoing problem with components that:
>
> - are defined with ConfigurationPolicy.OPTIONAL
> - have a configuration defined in the provisioning model
>
> What can happen is that the component is activated, is referenced and
> used, and at a later time is configured.
>
> For an example of this see SLING-6305 [1], where the
> LoginAdminWhitelist config is applied too late.
>
> Top of my head, some (probably bad) ideas are:
>
> 1) Make the component require a configuration
>
> This makes the component less flexible and we should aim for a minimal
> configuration with Sling.
>
> 2) Post-process the configurations using the slingstart-maven-plugin
> and adjust the configurationPolicy to be ConfigurationPolicy.REQUIRED
>
> This is a bit suprising and makes it harder for components to be
> switched to a default configuration after being provisioned.
>
> Suggestions would be greatly appreciated :-)
>
> Thanks,
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/SLING-6305
Re: Ensuring that components have a configuration when started
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2016-11-21 at 20:04 +0530, Chetan Mehrotra wrote:
> On Mon, Nov 21, 2016 at 7:01 PM, Robert Munteanu <ro...@apache.org>
> wrote:
> > Maybe you can suggest the correct value of the
> > sling.installer.requiredservices framework property for a service
> > with
> > a given PID
>
> From test case case it looks like following framework property should
> work
>
> sling.installer.requiredservices=resourcetransformer:org.osgi.service
> .cm,installtaskfactory:org.osgi.service.cm
Hm, unfortunately it does not. I set it initially, with no effect. Then
when I read your response I realised that the updated bundle is not
part of the launchpad, but even after the update it does not work.
Robert
Re: Ensuring that components have a configuration when started
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Nov 21, 2016 at 7:01 PM, Robert Munteanu <ro...@apache.org> wrote:
> Maybe you can suggest the correct value of the
> sling.installer.requiredservices framework property for a service with
> a given PID
From test case case it looks like following framework property should work
sling.installer.requiredservices=resourcetransformer:org.osgi.service.cm,installtaskfactory:org.osgi.service.cm
Chetan Mehrotra
Re: Ensuring that components have a configuration when started
Posted by Robert Munteanu <ro...@apache.org>.
Right, but I have no idea how to apply the fix after reading the issue
description :-)
Maybe you can suggest the correct value of the
sling.installer.requiredservices framework property for a service with
a given PID?
Thanks,
Robert
On Mon, 2016-11-21 at 15:53 +0530, Chetan Mehrotra wrote:
> I think this issue should have been fixed with SLING-5779. May be the
> new config that is exposed needs to be enabled for out of the box
> Sling setup?
> Chetan Mehrotra
>
>
> On Mon, Nov 21, 2016 at 3:50 PM, Robert Munteanu <ro...@apache.org>
> wrote:
> > Hi,
> >
> > I think we have an ongoing problem with components that:
> >
> > - are defined with ConfigurationPolicy.OPTIONAL
> > - have a configuration defined in the provisioning model
> >
> > What can happen is that the component is activated, is referenced
> > and
> > used, and at a later time is configured.
> >
> > For an example of this see SLING-6305 [1], where the
> > LoginAdminWhitelist config is applied too late.
> >
> > Top of my head, some (probably bad) ideas are:
> >
> > 1) Make the component require a configuration
> >
> > This makes the component less flexible and we should aim for a
> > minimal
> > configuration with Sling.
> >
> > 2) Post-process the configurations using the slingstart-maven-
> > plugin
> > and adjust the configurationPolicy to be
> > ConfigurationPolicy.REQUIRED
> >
> > This is a bit suprising and makes it harder for components to be
> > switched to a default configuration after being provisioned.
> >
> > Suggestions would be greatly appreciated :-)
> >
> > Thanks,
> >
> > Robert
> >
> >
> > [1]: https://issues.apache.org/jira/browse/SLING-6305
Re: Ensuring that components have a configuration when started
Posted by Chetan Mehrotra <ch...@gmail.com>.
I think this issue should have been fixed with SLING-5779. May be the
new config that is exposed needs to be enabled for out of the box
Sling setup?
Chetan Mehrotra
On Mon, Nov 21, 2016 at 3:50 PM, Robert Munteanu <ro...@apache.org> wrote:
> Hi,
>
> I think we have an ongoing problem with components that:
>
> - are defined with ConfigurationPolicy.OPTIONAL
> - have a configuration defined in the provisioning model
>
> What can happen is that the component is activated, is referenced and
> used, and at a later time is configured.
>
> For an example of this see SLING-6305 [1], where the
> LoginAdminWhitelist config is applied too late.
>
> Top of my head, some (probably bad) ideas are:
>
> 1) Make the component require a configuration
>
> This makes the component less flexible and we should aim for a minimal
> configuration with Sling.
>
> 2) Post-process the configurations using the slingstart-maven-plugin
> and adjust the configurationPolicy to be ConfigurationPolicy.REQUIRED
>
> This is a bit suprising and makes it harder for components to be
> switched to a default configuration after being provisioned.
>
> Suggestions would be greatly appreciated :-)
>
> Thanks,
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/SLING-6305