Hi all,
so I have done some more testing and found out that during first
startup, it's not only the configs that become active very late:
1. Bundles of feature :boot become active at start level 1
2. All other bundles become active at start level 30 (and not what is
configured in provisioning files, the start level is set after
context.installBundle())
3. Fairly late of start level 30, the configurations become effective
My initial idea was to fix the collaboration of modules [1] to register
the configs correctly (osgiInstaller.registerResource() calls
ConfigTaskCreator eventually, in theory there is no reason why all this
should not be able to happen during start level 1 just after the
configadmin bundle becomes active, but in reality all the asynchronicity
in the bundle make it really hard).
So two questions:
To mitigate 3. from above:
Would it be an option to just set the configs in
sling-org-apache-sling-launchpad-base directly? (I think Bertrand this
is what you suggested, but if somehow possible I'd even prefer to do it
without listener but synchronously for robustness). This would also
imply that the configs get registered again in launchpad-installer and
then normally installed (again), but maybe this is not a problem?
To mitigate 2. from above:
What could we do to ensure the bundles get activated in declared order
(respecting startlevel)? (I found switchstartlevel [2] but somehow it
didn't work for me)
-Georg
[1]
https://github.com/apache/sling-org-apache-sling-launchpad-installer
https://github.com/apache/sling-org-apache-sling-installer-core
https://github.com/apache/sling-org-apache-sling-installer-factory-configuration
[2]
https://github.com/apache/sling-org-apache-sling-installer-core/blob/7b2e4407baa45b79d954dd20c53bb2077c3a5e49/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L91
On 2019-04-16 08:44, Bertrand Delacretaz wrote:
Hi,
On Tue, Apr 16, 2019 at 8:19 AM Georg Henzler <[email protected]>
wrote:
...My proposal: We change the provisioning model in a way that all
mentioned configurations become active exactly with the start level of
org.apache.felix.configadmin....
Makes sense to me, I can't think of a good reason to activate configs
at specific start levels.
I suppose you just need a component that starts at level 1 and listens
for the ConfigAdmin service availability to implement this.
-Bertrand
