Carsten Ziegeler wrote > Robert Munteanu wrote >> On Tue, 2017-05-09 at 09:41 +0200, Oliver Lietz wrote: >>>> There is the assumption that if such a mapping is available the >>>> underlying service user is available as well - which unfortunately >>>> is >>>> wrong. In this sense we could also remove the whole concept again >>>> and >>>> simply assume that if the JCR resource provider is available, the >>>> service user is created. It's the same shaky assumption but just >>>> simpler :) >>> >>> AFAIR (I'm on holidays and have no time to check) the mapping is >>> registered >>> only when the service/system user is present. I had problems in >>> integration >>> tests where system users materialized after service user mapping >>> config was >>> processed and they failed. >> >> Looking at the code I don't see this happening. >> >> I agree that we should make it work properly. >> > > I think most of what I suggested can easily be implemented, the > main question is how can the service user implementation find out > which service users exist? > A provider could announce this by registering services but then > these services need to be associated with the given resource provider. > (Which of course is doable). Or we could add new API with something > like a boolean method asking for existence of a service user. >
One way of doing it is lazy registration of a "service user service". The jcr resource provider implementation could register service hooks. If now the service user mapper bundle is looking for a "service user service" for the jcr resource provider with a given name, the hook can query the user manager for the existence of such a user and if so dynamically register it. Or the jcr resource provider keeps track of all available service users and register such a service. Other resource providers requiring authentication would do something similar. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
