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 :)

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.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
[email protected]

Reply via email to