Well, one problem with this is that JcrResourceResolver uses support for this constant in order to support the "workspace":"path" notation. This can be worked around by exposing a package-protected method on JcrResourceResolverFactoryImpl which JcrResourceResolver would use instead.
My larger reservation is that this will break some of the places I've started to use multi-workspace. Specifically, when I adapt request.getResourceResolver() to a javax.jcr.Session, currently I get a Session logged into the workspace specified in the AuthenticationInfo object. Under this new scheme, I would get a Session logged into the default workspace. This isn't a blocker, just means I'd have to rewrite some code. Justin On 5/3/10 3:24 PM, Carsten Ziegeler wrote: > Hi, > > we now support multiple workspaces with a single resource resolver > (factory) by using the "workspace":"path" notation. > > However we still have a constant defined to specify the workspace for > login into the resource resolver factory. we should remove this to avoid > any potential problems and only use the new mechanism. > Therefore I think we should remove or deprecate the constant and not > support it by the resource resolver factories. > > As always, there is one problem with this: the new script resolver is > able to resolve scripts in the workspace of the request. We have to find > a different solution. The first change is to use the "workspace":"path" > notation inside the script resolver - this should be easy. > The only question is how to specify which workspace to be used? The main > part is the resolve(Http request, String) method. What about defining a > request attribute which could hold a potential workspace name and the > resource resolver than creates a resource path like "workspace:path"? > The script resolver can then easily to a resource.getPath() and pick the > workspace name from the path. > > WDYT? > Carsten
