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 <[email protected]>
> > :
> > 
> > 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
> 
> 

Reply via email to