On Tuesday 09 May 2017 07:31:53 Carsten Ziegeler wrote: > While working on the "configurationless" Sling, I noticed that the > ServiceUserMapped concept does not only create problems with zero > configurations but is also not working as expected. Right now, it > creates a false sense of safety. > > It is a good idea to express the requirement of a component to use a > specific service user as a dependency to a service registered in the > service registry. Therefore we created the ServiceUserMapped. However as > the name already applies, the existence of this service only means that > a *mapping* is available. It does not express whether the underlying > *service user* is available. Therefore the whole mechanism is creating > this false sense of safety and in reality does not provide the wanted value. > > 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. > Or we could try to make this work as expected. Now, a component using a > service user does not know which service user it will use as this is > configured in the mapping. I think this decoupling is a good idea. > Therefore the current dependency to a ServiceUserMapped is a good thing. > (Although the current use of @Reference in many places could be improved > to what we have now in the code - but that's OT for this thread). > > However, the automatic registration of the ServiceUserMapped service > just due to the existence of a mapping configuration is the part which > is wrong. In addition, we have to keep in mind that we might have many > resource providers not just one which is using service users. > Fortunately there are resource providers not requiring authentication > and these can be used without the existence of a service user. Taking > this into account, a resource provider using authentication should > announce which service users it knows, our implementation of the service > user mapper compares the mapping configuration with the existence of > service users in *all* resource providers requiring authentication and > if each of them provides such a service user, it will register the > ServiceUserMapped. Similar of no resource provider requires > authentication, the ServiceUserMapped can be registered as well. > > This will bring us a working and reliable solution and in addition > solves the configurationless part as well - for example if you only have > the file resource provider, the ServiceUserMapped can be registered and > no additional configuration is required. > > There is one neglectable "problem" with this approach. It assumes that > potentially the requested service user will access all (authenticated) > resource providers while in practice it might be the case that only one > is hit. > > So, to keep the long story short: either we remove the ServiceUserMapped > concept or we do it right. The way it is today is not really solving the > problems it should. +1 for doing it right Regards, O. > Regards > Carsten
