On Wednesday 09 November 2016 11:31:11 Julian Sedding wrote: > I'm ok with a pragmatic approach for the moment. Let's see how long it > takes until that bites us ;)
*sigh > I think however, that Betrand already mentioned a fair additional > use-case: content updates that can be executed *before* the repository > becomes visible to other services. right, that is a valid use case (while users and paths should be "dynamic" – after a repository is made available to other components) Regards, O. > Regards > Julian > > On Wed, Nov 9, 2016 at 11:27 AM, Carsten Ziegeler <[email protected]> wrote: > > Bertrand Delacretaz wrote > > > >> On Wed, Nov 9, 2016 at 10:59 AM, Carsten Ziegeler <[email protected]> wrote: > >>> ...So what about going the pragmatic way atm and adding a configuration > >>> which simply says "requires initializer" and it's enabled by default?... > >> > >> The whole point of RepositoryInitializer is to allow things to run > >> *before* any component sees the SlingRepository service. This is > >> needed for example for content migrations when upgrading Sling-based > >> apps. > >> > >> If we don't have time to implement a general solution as discussed > >> here (I don't right now) I'm ok with adding a > >> "repositoryinitializer.required.count" configuration and waiting on > >> that number of services to be available, with clear login messages to > >> make the whole thing self-explaining. > >> > >> That's not ideal but reasonably robust if correctly configured, and > >> good logs should help make that happen - like warning if more services > >> than expected are or become available. > > > > Again, the whole Sling code base has only one implementation of > > RepositoryInitializer. So why should we check for N ? Do we really > > expect atm that someone will register such a service atm? > > We don't provide any way to do so. > > > > Carsten > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > [email protected]
