Carsten- I've only had a few hours to use the new implementation, so I may have more comments, but my initial comments are:
* It should be noted somewhere that the default workspace is always used for authentication. * We no longer have an *obvious* place to set the workspace for a request. When workspace selection was integrated with auth, it was clear (I thought) that you needed an AuthenticationHandler or an AuthenticationInfoPostProcessor. But now, workspace selection is detached from auth, yet auth is the only place within Sling you can effectively do workspace selection. I had originally thought you could use a Filter, but Sling Filter processing occurs after resource resolution, so you either have to use a Filter external to Sling or use the auth extension points anyway. I would really like my "Selected workspace X because of Y" to be loggable in RequestProgressTracker, but this won't work if I use a "regular" Filter. Perhaps we need a new type of Filter that would get invoked before resource resolution. * At first glance, it appears to me that you've removed the "fallback to the default workspace" logic we had in the script resolver. But I don't actually use that (and I don't think we have integration tests for it), so I'm not sure. Removing this fallback is OK with me (Bertrand may feel differently), but it should be noted in SLING-1446. Finally, in terms of returning the real resource resolver, this is OK with me, but should be done soon. As I mentioned before, one of my needs is to get access to a session in the request-specific workspace. First I did: session = request.getResourceResolver().adaptTo(Session.class) then I switched to: session = request.getResource().getResourceResolver().adaptTo(Session.class) now I will need to: session = request.getResource().adaptTo(Node.class).getSession() Justin On Sun, May 23, 2010 at 9:42 AM, Carsten Ziegeler <[email protected]>wrote: > Hi, > > as recently discussed, I changed the implementation of the (jcr) > resource resolver (and factory) and the script resolver a little bit > with respect to workspace handling. > > The script resolver now relies completly on the resource resolver for > workspace related resolving. > > The resource resolver can be used with the {workspace}:[path} syntax ti > resolve resources in a particalur workpace. If the current user is now > allowed to login into that workspace, this is treated as a resource not > found. > > The commons auth and the login mechanism there does not support a > workspace property anymore. This is now more or less handled > transparently behind the sense. > > I hope I did not break something - but there might be new bugs with the > changes (although this should only affect workspace related resolving) :) > > There is currently one thing which I think we have to change: if you > resolve a resource with a workspace prefix, the resource resolver > returned by resource.getResourceResolver() resolves resources in that > workspace first. (Internally a resource resolver for each workspace is > created - on demand. And this internal resource resolver is returned for > such a resource). > I think we should change this and always return the "real" resource > resolver. > > WDYT? > > Carsten > -- > Carsten Ziegeler > [email protected] >
