Hi,

I'm looking at SLING-4556, which is about the OakSlingRepositoryManager
being restarted at least once during startup. Those restarts leads to
strange behaviours, with the obvious one being a NPE in
DiscoveryServiceImpl#activate, but see also OAK-3152 [1].

I discovered that this was due to the
 org.apache.sling.installer.factory.configuration bundle being started
at start level 20, which means that no configuration was available
until then. 

In more detail, any component that:

- belongs to a bundle with start level < 20
- specifies configuration policy = optional 
- has a configuration defined

is activated once when the bundle is started and then
deactivated/activated when the configuration is  installed. This leads
to the OakSlingRepositoryManager itself being activated/deactivated
through a dependency chain ( OakSlingRepositoryManager ->
SecurityProviderImpl -> AuthenticationConfigurationImpl ).

My fix involves:

- moving org.apache.sling.installer.factory.configuration to the :boot
feature
- moving org.apache.sling.jcr.oak.server to start level 16

The org.apache.sling.installer.factory.configuration has only
dependencies which are contained in the :boot feature, so there is no
trouble there. Also, I think it's more natural to have configurations
already present when a configurable component is activated.

One possible objection is that start levels should not be used for
functional purposes. I acknowledge that but this is not a functional
issue - it's just minimising component restarts which a) increase
startup time and b) can expose bugs in other components not under our
control.

That being said, please take a look at the patch [2] attached to SLING
-4556 [3] and let me know if you see any issues with it.

Thanks,

Robert


[1]: https://issues.apache.org/jira/browse/OAK-3152
[2]: https://issues.apache.org/jira/secure/attachment/12747567/SLING-45
56-1.patch
[3]: https://issues.apache.org/jira/browse/SLING-4556

Reply via email to