Carsten Ziegeler wrote: > Hi, > > I think we should not let the ResourceManager extend the > ResourceResolver as this complicates its usage. > If you want to get the ResourceManager you currently have to get it from > the request via the getResourceResolver() method and then try to down > cast it. > > If we are in an OSGi environment and you want to implement a service > depending on the resource manager, you have to depend (bind) the > resource resolver and test if it is a resource manager. This is a little > bit ugly as you just want to use a resource manager. > As the resource manager gets a Resource object via its method I think we > can decouple the interfaces without any problems. > > I currently see no benefit in extending the resource resolver for the > resource manager. Therefore I propose to make it a standalone > interface/service and add a getResourceManager() method to the sling > request which might return null if no resource manager is available. > Or, if we don't want to add the getResourceManager() method, one can get > the resource manager through the service locator (which is fine for me > as well). > In addition we should perhaps think of a better name than resource > manager... > I'm only speaking of the api here - the impl will most propably shared between the two services (it could be one component registering for both interfaces)
Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
