This bit:
> Looking at SlingServletResolver, something like this is needed anyway in
> order to make SlingServletResolver independent of JCR.
is wrong. Not sure what I was thinking.
But... in figuring out I was wrong, I came up with a better solution:
Instead of:
> ResourceResolverFactory needs a method that says "create a new
> ResourceResolver, using this other ResourceResolver as a guide, but with
> alternate authentication.
How about if ResourceResolver has a "sudo" method which returns a new
ResourceResolver. Then SlingServletResolver could do something like this
when resolving:
ResourceResolver scriptResolver =
request.getResourceResolver().sudo(scriptUser);
try {
... resolve ...
} finally {
scriptResolver.close();
}
WDYT?
Justin
On Thu, Mar 18, 2010 at 12:40 PM, Justin Edelson <[email protected]>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).
>
> On 3/18/10 2:19 AM, Carsten Ziegeler wrote:
> > Right, the question here is how to solve use cases like Justin's and I
> > think that solving this through the resource tree is the most elegant
> > way (and we have nearly everything for this in place since we started
> > with the resource tree).
> >
> > Carsten
>
> I thought about this a lot yesterday and I'm still of the mind mounting
> workspaces inside the resource tree is NOT the right way to accomplish
> the use cases I sent. This isn't to say we shouldn't do that, but I
> think we're fundamentally describing two different things.
>
> 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).
>
> 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).
>
> 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.
>
> Justin
>
