Hi, Justin Edelson wrote > Hi, > > This is a longish email which I wrote in bursts over a few hours, so I > apologize in advance if it's not completely coherent. Basically, I think > we should do both... allow for the request's workspace to be used for > script resolution AND provide the ability to mount non-default > workspaces under the resource tree (i.e. /security -> the root node of > the security workspace). yes, seems to make sense.
> > To my mind, at present Sling's resource tree is composed of a JCR > workspace with 0 or more resource providers layered on top of the > workspace's node tree (bundle, fs, etc.). For the purpose of the use > cases I described yesterday, I am talking about replacing the base layer > of the resource tree. We allow this today, it just doesn't work for > script resolution (because of the specific need in script resolution to > use a different session). yes, but it's not just the session but also the path collision - the same script path in different workspaces. > I can see how a combination of mounting non-default workspaces and > /etc/map can accomplish some of what I described. However, since both > /etc/map and SlingServletResolver.getSearchPath() are static, it feels > very limited. For example, if I wanted to service a request for > http://v1.site.com/content/index.html using a node called /content/index > and a script in a node /apps/myco/page, where both nodes are in the v1 > workspace, I would need an /etc/map entry with > v1.site.com > sling:internalRedirect=/v1 > > AND > the search path needs to be /v1/apps, /v1/libs, /apps, /libs > > Then I add v2. > v2.site.com > sling:internalRedirect=/v2 > > AND > the search path needs to be /v2/apps, v2/libs, /v1/apps, /v1/libs, > /apps, /libs > > > There is now no way to properly serve scripts from v1 anymore (AFAICT). Ok, I think I got your use case now better :) > Perhaps a different way of looking at this... > > ResourceResolverFactory needs a method that says "create a new > ResourceResolver, using this other ResourceResolver as a guide, but with > alternate authentication." > > Looking at SlingServletResolver, something like this is needed anyway in > order to make SlingServletResolver independent of JCR. > > Again, none of this is to say that we shouldn't ALSO do a secondary > resource provider which mounts a non-default workspace within the > resource tree. > > Finally, it's worth noting that mounting additional workspaces under the > resource tree doesn't obviate the need for initial content loading and > observation/event support across multiple workspaces. In fact, it makes > the latter more complicated in that JCRResourceListener now needs to map > a path in a non-default workspace to an absolute resource path. I would > be surprised if JCRResourceListener was the only place we assumed that > JCR path == resource path. In fact the listener does not assume this :) It's already prepared to handle the case where the jcr is not mounted at / (but I haven't tested it yet). Now, the assumption jcr path == resource path can't be guaranteed by Sling. The only thing we can guarantee are: 1. resourceResolver.getResource(resource.getPath()).equals(resource) (let's assume we have implemented equals correctly...) 2. resource.adaptTo(Node.class) returns a node for all jcr backed resources If we use different assumptions throughout the Sling code we should fix this. After thinking about this a little bit more I had another idea which I haven't thought through until the end, but I think it's worth sharing it :) What about adding the workspace if it is not the default workspace to the resource path, so in your cases, resource getPath returns something like v1:/content/index, v2:/content/index or just /content/index. We can add support for such paths in the resource resolver. And this information can be easily picked up by the script resolution and handled accordingly. There should only be a few places where we need to add handling of these new paths. And if people are not working with workspaces everything stays the same. Again, just a rough idea.... Carsten -- Carsten Ziegeler cziege...@apache.org
