[ 
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363116#comment-14363116
 ] 

Marius Petria commented on SLING-4461:
--------------------------------------

bq. So, with filters we can cover everything from most narrow requirements to 
broadest possible openness as supported by the API.

Right, however the concept of defaults becomes a bit twisted: defaults are not 
really fallbacks but proper sub service names. For example in an application 
that always uses ServiceUserMapped to ensure proper ordering, an administrator 
cannot freely add a default in order to satisfy all subServices for a bundle, 
so the utility of defaults is zero. They are no longer an implementation 
(configuration) detail, that permit an arbitrary number of subServices to be 
satisfied with a single configuration. The nonexisting serviceName is actually 
a "special" (empty) subServiceName that is part of the contract, and can be 
referenced by developers. As you said we can make also the global fallback a 
part of the contract, but I cannot see an usecase for specifying a dependency 
on a global default.

I think that if we accept that default names (non existing subServiceName 
property, default property) are part of the contract, then we do not need to 
change anything, we just have a not so useful notion of defaults.

 

> Remove fallbacks for service users resolution
> ---------------------------------------------
>
>                 Key: SLING-4461
>                 URL: https://issues.apache.org/jira/browse/SLING-4461
>             Project: Sling
>          Issue Type: Improvement
>          Components: Service User Mapper
>            Reporter: Marius Petria
>
> ServiceUserMapperImpl has several levels of fallback for service user 
> resolution (fallback to bundle default, or to global default). While this 
> offers a lot of flexibility, it introduces non-determinism in a security 
> feature. If defaults are set, it can happen (especially at startup) that code 
> is executed using different serviceUsers, e.g. a component can execute using 
> the bundle default or global default until its specific subService is 
> available, and it can be easily imagined how this can cause subtle errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to