There is indeed a very valid use case for ServiceUserMapped and that is using the service resolver in the activate() method. If the configuration or system user is not available at that point, the activate() fails with an exception and the component is never being restarted (even if at a later point in time both configuration and the bound system user is there). This functionality is IMHO crucial, because at least during development it could be that the configuration mapping is not yet provided when the service would be first started. Just failing once and never retry again, is IMHO against all OSGi services practice. So having an explicit dependency against that feels right. If it is too complicated to check for the existence of the service user we could at least keep the current dependency, which enforces that the service is not started until at least the configuration is available. This is very helpful and should not be removed. Konrad
> On 11. May 2017, at 09:39, Carsten Ziegeler <[email protected]> wrote: > > From the few responses in this thread I have the feeling that the > preference is on implementing this correctly. > > However, we're still lacking a good idea on how exactly to implement this. > > Now, I think it is not a good idea to expose each and every service user > as a service in the service registry. I don't want to make that > information generally available. But then the question is how can the > service user mapper implementation find out about this? > > The other option we have is to accept that this is not worth the effort > and we simply remove the ServiceUserMapped support (deprecate it and > remove the usage in Sling). Service users are a very low level > configuration of the data store and we could assume that this is > correctly configured - as well as the mapping. > > Thoughts? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
