Hi Carsten, 2017-05-11 9:39 GMT+02:00 Carsten Ziegeler <[email protected]>:
> 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. > I think deprecating makes sense, indeed service users seem rather like configurations than resources to be managed during the app runtime. Also, if a component still needs to detect this miss configuration upon activation, it could still do it by explicitly invoking ServiceUserMapper#getServiceUserID. Regards, Timothee > > Thoughts? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
