On 5/4/10 5:34 AM, Carsten Ziegeler wrote: > Justin Edelson wrote >> 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. > Yepp. > >> 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. > Yes, that would require that you change your code :( > Now, I think the multi workspace support is far better than the old > solution where two different resource resolvers might deliver different > content for the same path. > > It would be great if you could change your code :) I think for the use case I mentioned, I can do: request.getResource().getResourceResolver().adaptTo(Session.class)
and get the same thing. > > The only question is, if this would work for you. Which means, if just > the resolve(http request, string) method uses the workspace attribute, > does resolving other resources through the resource resolver than work > as expected? I think so. It seems like script includes will work fine with this which was another concern. Justin > > Carsten > > >> >> 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 >> >> > >
