I'm ok with a pragmatic approach for the moment. Let's see how long it takes until that bites us ;)
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. 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] >
