This pattern is usually used with registering event handlers as observation listeners. With the new observation api we have a more elegant solution: you can register the listener with a relative path and the search paths are automatically added.
As all our event handlers should move to the new observation api, I don't see a reason to add new api - unless there is another good use case. Carsten Bertrand Delacretaz wrote > Hi, > > I was looking at a few cases where we use an administrative > ResourceResolver just to get the current search paths, for example in > ScriptCacheImpl [1], the (simplified) pattern is: > > ResourceResolver resolver = rrf.getAdministrativeResourceResolver(null); > searchPaths = resolver.getSearchPath(); > resolver.close(); > > Conceptually there's no need to have a resource resolver to get the > search path, nor should it be necessary to login to anything - the > search path is just a configuration in > ResourceResolverFactoryActivator. > > To avoid having to create service users just for this, I suggest > creating a service that provides the search path, and letting the > ResourceResolverFactoryActivator provide that service. We can then get > rid of a number of admin sessions and resolvers, in various places. > > WDYT? > > -Bertrand > > [1] > https://github.com/apache/sling/blob/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/ScriptCacheImpl.java > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
