Definitely +1 on doing this right. Regardless of the above, the goals I read in this thread are the following: - only register a service if the required service-user is available (ServiceUserMapped) - announce service-users lazily
An implementation could consist of a component, let's call it ServiceUserRegistry. The ServiceUserRegistry looks for ServiceUserProvider services (e.g. a SlingRepository implementation could also implement this interface). Furthermore, the ServiceUserRegistry implements FindHook (in theory I think a ListenerHook would be better, but this does not work with the current Felix SCR implementation) looking for requests for ServiceUserMapped services and their (optional) sub-service name. If a service is requested that is not yet available, the ServiceUserRegistry asks all ServiceUserProviders if they can provide a suitable service user. If that is the case it registers an appropriately configured service (this could be achieved by means of a ComponentFactory). Unregistering of service users that go away could be handled on two levels: 1. if a ServiceUserProvider is unregistered, all service-users it provided need to be unregistered as well. 2. A ServiceUserProvider needs to be able to signal the ServiceUserRegistry that a user has disappeared. With the introduction of a default service-user mapping, at least the name ServiceUserMapped seems no longer appropriate. We could rename it to ServiceUser or ServiceUserAvailable. And/or I could imagine going a step further and provide a ServiceResourceResolverFactory (an interface with a single method "createResourceResolver(Map authInfo)" or maybe a second one with no args for convenience). A consumer would inject the ServiceResourceResolverFactory instead of a ResourceResolverFactory. The @Reference target filter could optionally indicate a subservice name. Please feel free to rip this apart or improve on it! ;) Regards Julian On Thu, May 11, 2017 at 10:49 AM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi, > > On Thu, May 11, 2017 at 9:39 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> ...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 the main goal of ServiceUserMapped is to have components wait > at startup until the mappings (+ service users but that doesn't work) > are available. > > So "configuration is correct" is just part of the deal. > > How about having the code that registers the ServiceUserMapped markers > wait for the SlingRepository service? > > If service users are registered via repoinit, waiting for > SlingRepository waits for all of them, assuming the configuration is > correct. And if not those services will generally fail loudly. > > -Bertrand