sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <>
Subject Re: Revisiting ServiceUserMapped
Date Thu, 11 May 2017 09:09:54 GMT
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.

> On 11. May 2017, at 09:39, Carsten Ziegeler <> 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

View raw message