Hi all, As a followup to this, we might probably even drop the SlingRepository interface (in the jcr/api bundle) and replace some functionality of the AbstractSlingRepository (in the jcr/base bundle) with the new ResourceResolverFactory:
* SlingRepository.getDefaultWorkspace() -- do we really need this or shouldn't we just use whatever the underlying repository defaults to ? * SlingRepository.loginAdministrative() -- replaced by ResourceResovlerFactory.getAdministrativeResourceResolver * AbstractSlingRepository configuration for anonymous and administrative user: Replaced by configuration for the new ResourceResovlerFactory.getAdministrativeResourceResolver and getAnonymousResourceResolver methods Maybe we could even completely drop the SlingRepository interface ? WDYT ? I have updated the proposal accordingly. Regards Felix Felix Meschberger schrieb: > Hi all, > > After bearing this idea in my mind for quite some time and only > discussing it in small circles, I would like to open up the discussion > on this. > > Point is, that to get a ResourceResolver is currently quite clumsy. You > need to get two services ([Sling]Repository and JcrResourceResolver) and > two method calls ([Sling]Repository.login and > JcrResourceResolver.getResourceResolver) to finally get a > ResourceResolver. In addition you have to tie your code to a package, > you do not really need, since primarily you need a ResourceResolver. > > My proposal is to add a first-class Sling service interface called > ResourceResolverFactory which allows you to get a ResourceResolver > instances in one single shot. The proposal also allows for much more > flexibility in building the Resource tree made of ResourceProviders > where each ResourceProvider itself may actually be provided by a > ResourceProviderFactory. > > Please find the proposal at [1] and lets start the discussion. > > Regards > Felix > > [1] > http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html >
