On Wednesday 09 November 2016 11:21:19 Carsten Ziegeler wrote: > Oliver Lietz wrote > > > On Wednesday 09 November 2016 10:58:04 Bertrand Delacretaz wrote: > >> Hi, > >> > >> On Wed, Nov 9, 2016 at 10:46 AM, Carsten Ziegeler <cziege...@apache.org> > > > > wrote: > >>> ...if the same client does so without adjusting the list > >>> of required names then the initializer might not be used either.... > >> > >> We can make this robust by having an explicit list of required > >> services, waiting for them to become available and complaining if > >> unlisted services of the same type appear. > >> > >> So for a dependency on a service S the client component is configured > >> with > >> > >> S.required.roles = "roleA, roleB, roleC" > >> > >> And each instance of S must be configured with a "role" system property. > >> > >> And the component that uses them (or maybe a generic utility to handle > >> such cases, added to bundles/commons/osgi) waits until this exact list > >> of roles is available, and complains if it finds any S services > >> without a role. > > > > In case of repoinit (creating users, paths and setting ACLs), I'm not sure > > if using SlingRepositoryInitializer and depending on activation order is > > the best way at all. Components need to handle absence of users, paths > > and ACLs gracefully anyway. And we have already a requirement to execute > > repoinit statements after a repository is initialized. > > Right, but that is a different thing and will work. The code that reads > the statements > can simply call the required services. That is independent from this > issue I think. > This problem is more about the initial repoinit from the provisioning model
Well, you cannot simply depend on repository initializers (e.g. runtime issues, SLING-6182) and there is nothing special in the initial repoinit. Though I agree there should be a mechanism to ensure initializers are executed before the repository is made available (mentioned content migration, etc). Regards, O. > Regards > Carsten
