Re: multi-workspace support in script resolution
On 3/19/10 10:16 AM, Felix Meschberger wrote:
>> ResourceResolver scriptResolver =
>> request.getResourceResolver().sudo(scriptUser);
>> try {
>> ... resolve ...
>> } finally {
>> scriptResolver.close();
>> }
>>
>> WDYT?
>
> +1 but name it "impersonate" to align it with JCR API.
OK, just so long as we remember that
ResourceResolver[Factory].impersonate() can't just delegate to
Session.impersonate(). ResourceResolver[Factory].impersonate() should
always work whereas Session.impersonate() can fail based on access
control. That's why I picked sudo... but there are other ways of
remembering the implementation details :)
>
> This would also allow us to reconsider another "problem" we have: The
> Commons Auth bundle currently supports a sudo parameter and cookie to
> actually impersonate another user after initial primary login.
>
> Since I am not sure, whether support for such sudo is correct in the
> Commons Auth layer, it would be usefull to have an impersonation support
> on the ResolverResolver[Factory] level.
>
> We could then move the support for sudo from Commons Auth to the Sling
> Main Servlet, where IMHO it is more appropriate.
>
> Having said this, it might probably be more inline with the rest of the
> API to have a new method on the ResourceResolverFactory:
>
> ResourceResolver impersonate(ResourceResolver resolver,
>Map credentials)
That'd be fine too. I just think having it be on the ResourceResolver
would lead to cleaner code.
Thanks,
Justin
>
> Regards
> Felix
>
>>
>> Justin
>>
>> On Thu, Mar 18, 2010 at 12:40 PM, 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).
>>>
>>> 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 ==
Re: multi-workspace support in script resolution
Hi Justin,
thanks a lot for your swift response.
> I think the subject of this thread is slightly misleading... it really
> should be "scripts should be resolved from the same workspace as
> resources". Which is essentially the summary of SLING-1446.
ahhh ok, that definitely makes more sense...
>> They are not for separating things out, like user A has a workspace
>> and user B has
>> a workspace, they are also not for separation by type.
> I have to stop you there. user-specific workspaces seem like a perfectly
> legitimiate use of workspaces IF those users are editing the same
> content tree.
Agreed. Which would make in turn use of merge() update() and clone() ;)
> Imagine four workspaces:
> 1) user1
> 2) user2
> 3) trunk
> 4) publish
> A node is created in user1 at /content/index, then clone() is called in
> trunk [i.e. clone("user1", "/content/index", "/content/index", false)].
> The node is then cloned into user2 [i.e. clone("trunk",
> "/content/index", "/content/index", false)]. User2 makes some changes in
> their workspace, saves, and then updates the node in trunk
> [node.update("user2")]. Finally, the node is clone from trunk to publish
> and is user-facing.
> The key point I've understood about workspaces and their appropriate use
> is that workspaces are supposed to represent the same content tree.
> Having private working copies doesn't seem to violate this.
Absolutely. I agree with you. Maybe I should clarify that in the wiki...
I was mostly referring to a usecase of multi-tenancy that people sometime
mistake as a good usecase for workspaces.
> By the by, something to consider for JCR 3 is that clone/update/merge
> all operate from the perspective of the "target" workspace (i.e. the
> workspace being cloned into, updated, merged). For promotion workflows,
> I believe corresponding methods called from the source workspace/session
> would be more natural, similar to how "git push" works.
Hmm... Good point. Maybe even JCR 2.1.
I think the issue is that to make modification in a workspace other than the
one that you have a session to is something that we lack some machinery
for...
thanks for the follow-up.
regards,
david
Re: multi-workspace support in script resolution
Hi,
On 19.03.2010 04:15, Justin Edelson wrote:
> 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?
+1 but name it "impersonate" to align it with JCR API.
This would also allow us to reconsider another "problem" we have: The
Commons Auth bundle currently supports a sudo parameter and cookie to
actually impersonate another user after initial primary login.
Since I am not sure, whether support for such sudo is correct in the
Commons Auth layer, it would be usefull to have an impersonation support
on the ResolverResolver[Factory] level.
We could then move the support for sudo from Commons Auth to the Sling
Main Servlet, where IMHO it is more appropriate.
Having said this, it might probably be more inline with the rest of the
API to have a new method on the ResourceResolverFactory:
ResourceResolver impersonate(ResourceResolver resolver,
Map credentials)
Regards
Felix
>
> Justin
>
> On Thu, Mar 18, 2010 at 12:40 PM, 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).
>>
>> 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
Re: multi-workspace support in script resolution
Hi, On 3/19/10 2:43 AM, Carsten Ziegeler wrote: > 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. Fantastic. I'll start with the former :) >> 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. That's OK. If the same script path exists in different workspaces, my point is that you should get the script that is the in the same workspace as that which was used for resource resolution. To be clear, I'm not contemplating having SlingScriptResolver discover scripts across workspaces and then rank them - the ranking needs to be local to a workspace. ... >> There is now no way to properly serve scripts from v1 anymore (AFAICT). > Ok, I think I got your use case now better :) Superb. ... >> >> 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). Ah, you're right. But this option is not used anywhere. > Now, the assumption jcr path == resource path can't be guaranteed by > Sling. But it does look like there is an assumption that a jcr path can be transformed into a resource path in an consistent manner. This means that the mounting of workspaces inside the resource tree has to be static. Not sure if this is a problem or not. ... > 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. If we're going to do that, why not just: resource.getWorkspace() ? I'm going to go ahead and commit my modifications. They should be entirely backwards-compatible and it seems like we have some consensus that, although there may be other needs, this is a reasonable enough place to start. BTW, after working with SlingScriptResolver in depth, I'm really interested to see that get cut over to ResourceResolverFactory :) Thanks, Justin > > 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
Re: multi-workspace support in script resolution
On 3/19/10 2:59 AM, David Nuescheler wrote:
> I just saw the topic of this thread and thought i would like to weigh in on
> this conversation...
I think the subject of this thread is slightly misleading... it really
should be "scripts should be resolved from the same workspace as
resources". Which is essentially the summary of SLING-1446.
> Workspaces are just about one of the most frequently abused feature
> of JCR and I have a feeling that this thread may forget what workspaces
> are for.
Nope. The specific use cases I posted were in line with, uh, your model.
At least I think they are.
> Workspaces are for .clone(), .merge() and .update() [1]
>
> They are not for separating things out, like user A has a workspace
> and user B has
> a workspace, they are also not for separation by type.
I have to stop you there. user-specific workspaces seem like a perfectly
legitimiate use of workspaces IF those users are editing the same
content tree.
Imagine four workspaces:
1) user1
2) user2
3) trunk
4) publish
A node is created in user1 at /content/index, then clone() is called in
trunk [i.e. clone("user1", "/content/index", "/content/index", false)].
The node is then cloned into user2 [i.e. clone("trunk",
"/content/index", "/content/index", false)]. User2 makes some changes in
their workspace, saves, and then updates the node in trunk
[node.update("user2")]. Finally, the node is clone from trunk to publish
and is user-facing.
The key point I've understood about workspaces and their appropriate use
is that workspaces are supposed to represent the same content tree.
Having private working copies doesn't seem to violate this.
> Usually when people use workspaces without using merge, clone or update they
> usually want to either use Access Control and the hierarchy or
> separate repositories.
> Workspaces are not a good solution for either of the two.
By the by, something to consider for JCR 3 is that clone/update/merge
all operate from the perspective of the "target" workspace (i.e. the
workspace being cloned into, updated, merged). For promotion workflows,
I believe corresponding methods called from the source workspace/session
would be more natural, similar to how "git push" works.
Justin
>
> regards,
> david
>
> [1]
> http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.
Re: multi-workspace support in script resolution
I just saw the topic of this thread and thought i would like to weigh in on this conversation... Workspaces are just about one of the most frequently abused feature of JCR and I have a feeling that this thread may forget what workspaces are for. Workspaces are for .clone(), .merge() and .update() [1] They are not for separating things out, like user A has a workspace and user B has a workspace, they are also not for separation by type. Usually when people use workspaces without using merge, clone or update they usually want to either use Access Control and the hierarchy or separate repositories. Workspaces are not a good solution for either of the two. regards, david [1] http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.
Re: multi-workspace support in script resolution
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
Re: multi-workspace support in script resolution
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 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
>
Re: multi-workspace support in script resolution
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
Re: multi-workspace support in script resolution
Alexander Klimetschek wrote > On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler wrote: >> Carsten Ziegeler wrote >>> I still have the feeling that mounting other workspaces into the >>> resource tree is the easier way. >>> With that we wouldn't need to change content loading, resource events >>> and maybe other things to come? >>> >>> Can we go a step back please and see what use cases we really have? >>> >> With the authentication info and the new resource resolver factory, we >> will have a mechanism to log in the user optionaly into resource providers. >> So for example if the authentication info contains a specific key/value >> pair, a login to a workspace resource provider which mounts workspace >> xyz at /xyz could be done. If the key/value pair is missing, the login >> to this resource provider is not successful and therefore in this >> resource tree /xyz does not exist. >> >> If now the resource resolver is configured to search scripts in >> /xyz/scripts, /apps, /libs everything should work. >> >> Just a rough idea. > > Hmm, this is interesting to see as in Jackrabbit we currently discuss > that for Jackrabbit 3.0 (major rewrite wrt persistence and internal > architecture) we would like to have a single tree in the persistence > layer with each workspace being mounted directly below the root. Which > is the same here ;-) > > I don't know too much of the (newer) internals of the resource tree > and its creation, but I think adding an additional layer with > workspaces by default creates new issues at various places. And it > gives people an invitation to use workspaces for things they are not > intended for (and in current Jackrabbit not optimized for!). That's > why I would not make that a default. > 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 -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler wrote: > Carsten Ziegeler wrote >> I still have the feeling that mounting other workspaces into the >> resource tree is the easier way. >> With that we wouldn't need to change content loading, resource events >> and maybe other things to come? >> >> Can we go a step back please and see what use cases we really have? >> > With the authentication info and the new resource resolver factory, we > will have a mechanism to log in the user optionaly into resource providers. > So for example if the authentication info contains a specific key/value > pair, a login to a workspace resource provider which mounts workspace > xyz at /xyz could be done. If the key/value pair is missing, the login > to this resource provider is not successful and therefore in this > resource tree /xyz does not exist. > > If now the resource resolver is configured to search scripts in > /xyz/scripts, /apps, /libs everything should work. > > Just a rough idea. Hmm, this is interesting to see as in Jackrabbit we currently discuss that for Jackrabbit 3.0 (major rewrite wrt persistence and internal architecture) we would like to have a single tree in the persistence layer with each workspace being mounted directly below the root. Which is the same here ;-) I don't know too much of the (newer) internals of the resource tree and its creation, but I think adding an additional layer with workspaces by default creates new issues at various places. And it gives people an invitation to use workspaces for things they are not intended for (and in current Jackrabbit not optimized for!). That's why I would not make that a default. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: multi-workspace support in script resolution
Carsten Ziegeler wrote > Carsten Ziegeler wrote >> I still have the feeling that mounting other workspaces into the >> resource tree is the easier way. >> With that we wouldn't need to change content loading, resource events >> and maybe other things to come? >> >> Can we go a step back please and see what use cases we really have? >> > With the authentication info and the new resource resolver factory, we > will have a mechanism to log in the user optionaly into resource providers. > So for example if the authentication info contains a specific key/value > pair, a login to a workspace resource provider which mounts workspace > xyz at /xyz could be done. If the key/value pair is missing, the login > to this resource provider is not successful and therefore in this > resource tree /xyz does not exist. > > If now the resource resolver is configured to search scripts in > /xyz/scripts, /apps, /libs everything should work. > > Just a rough idea. > Just as an additional rough idea, currently resource providers can overlay, for example we have the root provider mount the default workspace at /. However it is possible to mount lets say a file system at /libs/mystuff Now, maybe a similar approach could be done with resource providers for other workspaces. So if you have copies of stuff in a different workspace and want user A to use these copies, then the content of this workspace could be layed over the default content in the resource tree. I think this should be double without too many problems. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
On 3/17/10 11:03 AM, Carsten Ziegeler wrote: > I still have the feeling that mounting other workspaces into the > resource tree is the easier way. > With that we wouldn't need to change content loading, resource events > and maybe other things to come? > > Can we go a step back please and see what use cases we really have? > > Carsten A repository has three workspaces: 1) default 2) user1 3) user2 There are corresponding nodes in all three workspaces at the these paths: /index /apps/myco/page/html.esp User1 should be able to modify both of these nodes in the user1 workspace and be able to see those changes without impacting anyone else. Once User1 is satisfied with their changes, node.update() is invoked on the node in the default workspace (either by user1 or an admin process). ---and/or--- A repository has three workspaces: 1) trunk 2) v1 3) v2 all nodes are corresponding nodes. Nodes are cloned into v1 from trunk -> v1, then modified, then cloned into v2 from trunk. - As I understand it, with the "mounting into the tree" mechanism you're describing, the latter case would result in a tree like this: /trunk/index /v1/index /v2/index and then using /etc/map, requests for www.site.com would be prefixed with /trunk, v1.www.site.com would be prefixed with /v1, etc. This doesn't seem naturalistic to me. But I can't quite put my finger on why. Justin
Re: multi-workspace support in script resolution
Carsten Ziegeler wrote > I still have the feeling that mounting other workspaces into the > resource tree is the easier way. > With that we wouldn't need to change content loading, resource events > and maybe other things to come? > > Can we go a step back please and see what use cases we really have? > With the authentication info and the new resource resolver factory, we will have a mechanism to log in the user optionaly into resource providers. So for example if the authentication info contains a specific key/value pair, a login to a workspace resource provider which mounts workspace xyz at /xyz could be done. If the key/value pair is missing, the login to this resource provider is not successful and therefore in this resource tree /xyz does not exist. If now the resource resolver is configured to search scripts in /xyz/scripts, /apps, /libs everything should work. Just a rough idea. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
I still have the feeling that mounting other workspaces into the resource tree is the easier way. With that we wouldn't need to change content loading, resource events and maybe other things to come? Can we go a step back please and see what use cases we really have? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
On 3/17/10 10:50 AM, Felix Meschberger wrote: > Hi, > > On 17.03.2010 15:46, Justin Edelson wrote: >> Felix- >> I know this probably isn't a great answer, but I think we just have to >> start somewhere. If the answer is that this should happen in a branch, >> I'm fine with that, but I personally don't think it's necessary - any >> change along these lines should be able to be fully backwards compatible. > > No, if this can happen in a backwards-compatible way, then we don't > branch (except maybe for prototyping, but this does not seem to be > required here). > > I just want to list a few issues coming to my mind which we might > encounter along the way. If we keep them in mind (or at least JIRA ;-) ) > then fine. I'd suggest we tag these issues with "multiworkspace" in JIRA. Justin
Re: multi-workspace support in script resolution
Hi, On 17.03.2010 15:46, Justin Edelson wrote: > Felix- > I know this probably isn't a great answer, but I think we just have to > start somewhere. If the answer is that this should happen in a branch, > I'm fine with that, but I personally don't think it's necessary - any > change along these lines should be able to be fully backwards compatible. No, if this can happen in a backwards-compatible way, then we don't branch (except maybe for prototyping, but this does not seem to be required here). I just want to list a few issues coming to my mind which we might encounter along the way. If we keep them in mind (or at least JIRA ;-) ) then fine. Let's go. I think it is an interesting and usefull idea. > > Two other things come to mind are content loading and jcr resource events. Yep. Regards Felix > > Justin > > > On 3/17/10 10:06 AM, Felix Meschberger wrote: >> Hi, >> >> On 17.03.2010 02:45, Justin Edelson wrote: >>> Currently, although it's possible to log into different workspaces via >>> AuthenticationInfo (even if httpauth and formauth don't support this); >>> script resolution only happens against the default workspace. I don't >>> see any reason for this restriction - it seems to me you should resolve >>> scripts from the same workspace as the one resource was resolved from. WDYT? >> >> IIRC there have been some discussions around this (if only in my head >> with myself ;-) ) issue. It was merely about the question "will sling >> work if the main access is to another workspace ?" >> >> At that time, it (probably mostly) did, because the ScriptResolver used >> the ResourceResolver from the request, which was properly set up for the >> same workspace as the request. >> >> Nowadays, I fear it is not enough to just make the ScriptResolver >> multi-workspace aware -- the repository-based class loaders must also be >> made aware of this. Likewise the JSPScriptEngineFactory should probably >> also not compile scripts from a secondary workspace into the primary >> workspace /var/classes >> >> We might want to find a generic mechanism to be able to handle requests >> completely out of a secondary workspace - is this possible ? How ? >> >> Regards >> Felix >> >>> >>> I think I've resolved this locally (still testing), but wanted to get >>> some feedback before committing it. >>> >>> Thanks, >>> Justin >>> > >
Re: multi-workspace support in script resolution
Felix- I know this probably isn't a great answer, but I think we just have to start somewhere. If the answer is that this should happen in a branch, I'm fine with that, but I personally don't think it's necessary - any change along these lines should be able to be fully backwards compatible. Two other things come to mind are content loading and jcr resource events. Justin On 3/17/10 10:06 AM, Felix Meschberger wrote: > Hi, > > On 17.03.2010 02:45, Justin Edelson wrote: >> Currently, although it's possible to log into different workspaces via >> AuthenticationInfo (even if httpauth and formauth don't support this); >> script resolution only happens against the default workspace. I don't >> see any reason for this restriction - it seems to me you should resolve >> scripts from the same workspace as the one resource was resolved from. WDYT? > > IIRC there have been some discussions around this (if only in my head > with myself ;-) ) issue. It was merely about the question "will sling > work if the main access is to another workspace ?" > > At that time, it (probably mostly) did, because the ScriptResolver used > the ResourceResolver from the request, which was properly set up for the > same workspace as the request. > > Nowadays, I fear it is not enough to just make the ScriptResolver > multi-workspace aware -- the repository-based class loaders must also be > made aware of this. Likewise the JSPScriptEngineFactory should probably > also not compile scripts from a secondary workspace into the primary > workspace /var/classes > > We might want to find a generic mechanism to be able to handle requests > completely out of a secondary workspace - is this possible ? How ? > > Regards > Felix > >> >> I think I've resolved this locally (still testing), but wanted to get >> some feedback before committing it. >> >> Thanks, >> Justin >>
Re: multi-workspace support in script resolution
On 3/17/10 10:35 AM, Felix Meschberger wrote: > Strange. This hints at a servlet container issue, because the > getServerName method is defined to: Definitely possible. The app server was built pre-J2EE and plenty quirky. It's since been discontinued. Like I said, possible this was to workaround an issue and I just kept doing it long after it was necessary. Thanks for bringing me into the 21st century :) Justin > > Returns the host name of the server to which the request was sent. > It is the value of the part before ":" in the Host > header, if any, or the resolved server name, or the server IP address. > > So, the Host header should really be preferred > > Anyway ... > > Regards > Felix > >> >> Justin >> >>> >>> Regards >>> Felix >> >>
Re: multi-workspace support in script resolution
Hi,
On 17.03.2010 15:27, Justin Edelson wrote:
> On 3/17/10 10:16 AM, Felix Meschberger wrote:
>> Hi,
>>
>> On 17.03.2010 15:09, Justin Edelson wrote:
>>> On 3/17/10 9:49 AM, Felix Meschberger wrote:
>String host = request.getHeader("Host");
(NB this is what request.getServerName() reports; I would prefer to use
the API)
>>> (I seem to recall running into trouble with request.getServerName() and
>>> CDNs, so I just got into the habit of using the Host header.)
>>
>> Just curious: would that be formatting issues which the servlet
>> container could not resolve correctly ?
> This is what I remember:
>
> With our CDN at the time, where:
> CDN > Web Server > App Server
>
> User requested www.site.com, CDN requested origin.www.site.com.
>
> request.getServerName() = origin.www.site.com
> request.getHeader("Host") = www.site.com
Strange. This hints at a servlet container issue, because the
getServerName method is defined to:
Returns the host name of the server to which the request was sent.
It is the value of the part before ":" in the Host
header, if any, or the resolved server name, or the server IP address.
So, the Host header should really be preferred
Anyway ...
Regards
Felix
>
> Justin
>
>>
>> Regards
>> Felix
>
>
Re: multi-workspace support in script resolution
On 3/17/10 10:16 AM, Felix Meschberger wrote:
> Hi,
>
> On 17.03.2010 15:09, Justin Edelson wrote:
>> On 3/17/10 9:49 AM, Felix Meschberger wrote:
String host = request.getHeader("Host");
>>>
>>> (NB this is what request.getServerName() reports; I would prefer to use
>>> the API)
>> (I seem to recall running into trouble with request.getServerName() and
>> CDNs, so I just got into the habit of using the Host header.)
>
> Just curious: would that be formatting issues which the servlet
> container could not resolve correctly ?
This is what I remember:
With our CDN at the time, where:
CDN > Web Server > App Server
User requested www.site.com, CDN requested origin.www.site.com.
request.getServerName() = origin.www.site.com
request.getHeader("Host") = www.site.com
Justin
>
> Regards
> Felix
Re: multi-workspace support in script resolution
Hi,
On 17.03.2010 15:09, Justin Edelson wrote:
> On 3/17/10 9:49 AM, Felix Meschberger wrote:
>>>String host = request.getHeader("Host");
>>
>> (NB this is what request.getServerName() reports; I would prefer to use
>> the API)
> (I seem to recall running into trouble with request.getServerName() and
> CDNs, so I just got into the habit of using the Host header.)
Just curious: would that be formatting issues which the servlet
container could not resolve correctly ?
Regards
Felix
Re: multi-workspace support in script resolution
+1 I was in same situation - I can resolve that problem the resource will be selected as virtual domain, but for me it's little problematic that the scripts comes from default repository. (For security and versioning reasons sometimes some domain's repository better if separeted - for example if some script not secure enough some cases can access another user's nodes for example ), and I think the performance also can be better (maybe I'm not right but as I know the Path filtering differs from another's property - and the path filtering is a performance bottleneck of jackrabbit). I prefer that the scripts uses same repository as resources - in some situation this feature can be very usefull. Regards, Robert On Mar 17, 2010, at 2:20 PM, Bertrand Delacretaz wrote: > On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson > wrote: >> ... For example, if you think about how Google App Engine allows you to >> reference arbitrary versions of your application with a host name like >> version.appname.appspot.com (IIRC), one could imagine using the host >> header to select the workspace which corresponds to the requested >> version (and according to David's Model, this is a totally valid use of >> workspaces) > > I like the idea of using an HTTP header to select workspaces - and the > name of the "default scripts" workspace to use might be stored as a > property at the root node of the "private" workspace, or defined by > configuration of the script resource resolver. > > -Bertrand
Re: multi-workspace support in script resolution
On 3/17/10 9:49 AM, Felix Meschberger wrote:
>> public class WorkspacePicker implements AuthenticationInfoPostProcessor {
>>public void postProcess(AuthenticationInfo info, HttpServletRequest
>> request, HttpServletResponse response) {
>>String host = request.getHeader("Host");
>
> (NB this is what request.getServerName() reports; I would prefer to use
> the API)
(I seem to recall running into trouble with request.getServerName() and
CDNs, so I just got into the habit of using the Host header.)
>
>
>>if (host != null) {
>> String[] parts = host.split("\\.");
>> if (parts.length == 4) {
>>info.put(AuthenticationInfo.WORKSPACE, parts[0]);
>> }
>>}
>>}
>> }
>
> I wonder, whether and how this could be coordinated with the virtual
> host configuration stuff we do in the ResourceResolver /etc/map
> configuration. Maybe the ResourceResolverFactory knowing about the
> mapping could implement the interface and use the /etc/map configuration
> for this decision ?
To be clear... I wasn't actually suggesting that this WorkspacePicker be
included in Sling.
But yes, you could definitely implement a similar post processor using
/etc/map if the host nodes had something like:
sling:workspaceName = "wspName"
But as things currently stand, you couldn't implement it in the
JcrResourceResolverFactory class because there would be a circular
reference between commons.auth and jcr.resource.
Justin
>
>>
>>> - and the
>>> name of the "default scripts" workspace to use might be stored as a
>>> property at the root node of the "private" workspace, or defined by
>>> configuration of the script resource resolver.
>>
>> I'll probably just implement a configuration property for now; even if
>> we supported a root node property, we'll need a default.
>
> I prefer the configuration property anyway because a repository property
> is not congruent with how we do most of the configuration today (and
> additionally opens the door for very wierd stuff like wsp selected by
> client points to wspd1 for default resolution which in turn would point
> to wspd2 for default resolution and so forth)
>
> Regards
> Felix
Re: multi-workspace support in script resolution
Hi, On 17.03.2010 02:45, Justin Edelson wrote: > Currently, although it's possible to log into different workspaces via > AuthenticationInfo (even if httpauth and formauth don't support this); > script resolution only happens against the default workspace. I don't > see any reason for this restriction - it seems to me you should resolve > scripts from the same workspace as the one resource was resolved from. WDYT? IIRC there have been some discussions around this (if only in my head with myself ;-) ) issue. It was merely about the question "will sling work if the main access is to another workspace ?" At that time, it (probably mostly) did, because the ScriptResolver used the ResourceResolver from the request, which was properly set up for the same workspace as the request. Nowadays, I fear it is not enough to just make the ScriptResolver multi-workspace aware -- the repository-based class loaders must also be made aware of this. Likewise the JSPScriptEngineFactory should probably also not compile scripts from a secondary workspace into the primary workspace /var/classes We might want to find a generic mechanism to be able to handle requests completely out of a secondary workspace - is this possible ? How ? Regards Felix > > I think I've resolved this locally (still testing), but wanted to get > some feedback before committing it. > > Thanks, > Justin >
Re: multi-workspace support in script resolution
Hi,
On 17.03.2010 14:40, Justin Edelson wrote:
> On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
>> On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
> wrote:
>>> ... For example, if you think about how Google App Engine allows you to
>>> reference arbitrary versions of your application with a host name like
>>> version.appname.appspot.com (IIRC), one could imagine using the host
>>> header to select the workspace which corresponds to the requested
>>> version (and according to David's Model, this is a totally valid use of
>>> workspaces)
>>
>> I like the idea of using an HTTP header to select workspaces
>
> This is a naive implementation, but you can do this...
>
> @Component
> @Service
> public class WorkspacePicker implements AuthenticationInfoPostProcessor {
>public void postProcess(AuthenticationInfo info, HttpServletRequest
> request, HttpServletResponse response) {
>String host = request.getHeader("Host");
(NB this is what request.getServerName() reports; I would prefer to use
the API)
>if (host != null) {
> String[] parts = host.split("\\.");
> if (parts.length == 4) {
>info.put(AuthenticationInfo.WORKSPACE, parts[0]);
> }
>}
>}
> }
I wonder, whether and how this could be coordinated with the virtual
host configuration stuff we do in the ResourceResolver /etc/map
configuration. Maybe the ResourceResolverFactory knowing about the
mapping could implement the interface and use the /etc/map configuration
for this decision ?
>
>> - and the
>> name of the "default scripts" workspace to use might be stored as a
>> property at the root node of the "private" workspace, or defined by
>> configuration of the script resource resolver.
>
> I'll probably just implement a configuration property for now; even if
> we supported a root node property, we'll need a default.
I prefer the configuration property anyway because a repository property
is not congruent with how we do most of the configuration today (and
additionally opens the door for very wierd stuff like wsp selected by
client points to wspd1 for default resolution which in turn would point
to wspd2 for default resolution and so forth)
Regards
Felix
Re: multi-workspace support in script resolution
On Wed, Mar 17, 2010 at 14:17, Justin Edelson wrote: > In general, this works... But script resolution is different because it > uses a separate session. > > So today, you can write a minimal amount of code to switch workspaces > based on a request header. This isn't in the core. However, even if you > do this, scripts are still resolved from the default workspace. Ok, I agree, that should be configurable/codeable. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: multi-workspace support in script resolution
On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
> On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
wrote:
>> ... For example, if you think about how Google App Engine allows you to
>> reference arbitrary versions of your application with a host name like
>> version.appname.appspot.com (IIRC), one could imagine using the host
>> header to select the workspace which corresponds to the requested
>> version (and according to David's Model, this is a totally valid use of
>> workspaces)
>
> I like the idea of using an HTTP header to select workspaces
This is a naive implementation, but you can do this...
@Component
@Service
public class WorkspacePicker implements AuthenticationInfoPostProcessor {
public void postProcess(AuthenticationInfo info, HttpServletRequest
request, HttpServletResponse response) {
String host = request.getHeader("Host");
if (host != null) {
String[] parts = host.split("\\.");
if (parts.length == 4) {
info.put(AuthenticationInfo.WORKSPACE, parts[0]);
}
}
}
}
> - and the
> name of the "default scripts" workspace to use might be stored as a
> property at the root node of the "private" workspace, or defined by
> configuration of the script resource resolver.
I'll probably just implement a configuration property for now; even if
we supported a root node property, we'll need a default.
Thanks,
Justin
>
> -Bertrand
Re: multi-workspace support in script resolution
On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson wrote: >... For example, if you think about how Google App Engine allows you to > reference arbitrary versions of your application with a host name like > version.appname.appspot.com (IIRC), one could imagine using the host > header to select the workspace which corresponds to the requested > version (and according to David's Model, this is a totally valid use of > workspaces) I like the idea of using an HTTP header to select workspaces - and the name of the "default scripts" workspace to use might be stored as a property at the root node of the "private" workspace, or defined by configuration of the script resource resolver. -Bertrand
Re: multi-workspace support in script resolution
On 3/17/10 7:05 AM, Alexander Klimetschek wrote: > The question for one workspace per account / user / etc. pops up every > now and then on the jackrabbit mailing lists and the general answer is > to try to stay away from that as it just complicates things: why > having to work with multiple workspaces when you can just create > separate nodes? Workspaces are technically meant for > branching/cloning/merging in the JCR spec. Let's assume for the sake of argument that there are cases where using multiple workspaces is valid. Like everything, they can be abused. > Hence support for multiple workspaces in Sling should IMHO not change > URL resolution at all (workspace as part of URLs) and should default > to expecting a single workspace (as now). If people want to use > multiple workspaces, tinkering would be required and they should be > able to plug in different resource resolvers / authentication > mechanisms that might select a different workspace for each request > depending on some request headers etc. But this should not be a > primary feature and shouldn't lead to complication of the Sling > architecture, I think. In general, this works... But script resolution is different because it uses a separate session. So today, you can write a minimal amount of code to switch workspaces based on a request header. This isn't in the core. However, even if you do this, scripts are still resolved from the default workspace. Fundamentally, all I'm suggesting is that scripts should be resolved using the same workspace as that which was used to do the resource resolution. This is all internal to the servlet resolver, so it doesn't really complicate the architecture (in fact, it's a ongoing testament to the elegance of Sling's architecture that this change is contained to a single bundle) Justin > > Just my 2 euro-cents... > > Regards, > Alex > > On Wed, Mar 17, 2010 at 10:11, Carsten Ziegeler wrote: >> Bertrand Delacretaz wrote >>> Hi, >>> >>> On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler >>> wrote: ...In general I am not sure if it should be the authentication which defines what workspace is used. I rather could picture having a resource tree where workspaces are mounted at different locations in the tree. The script resolution could then be configured to search in the various workspaces >>> >>> I agree that this seems more logical than authentication switching >>> workspaces - but not sure how to retrofit this, as IIUC the current >>> tree does not consider workspaces. >>> >> It's right that the current implementation does not support this - but this >> is something we have on our plate for a long time now and with the >> change to the resource resolver factory - we started recently - we are >> close to this. >> >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org > >
Re: multi-workspace support in script resolution
On 3/17/10 4:41 AM, Carsten Ziegeler wrote: > I'm not sure what the best way is, but Sling is resource tree based. The > resource resolver (factory) gets configured with resource search paths > (/apps and /libs is default) for scripts. > The script resolver uses these paths to search for scripts. The script > resolver uses an own session and therefore resource resolver which is > not related to the current request. This allows a more secure > installation as the current user does not have to have read rights for > the scripts (or any other access rights). > > In general I am not sure if it should be the authentication which > defines what workspace is used. I rather could picture having a resource > tree where workspaces are mounted at different locations in the tree. > The script resolution could then be configured to search in the various > workspaces. Hmmm. But then you'd have to have a different search path per user to handle the script preview case I mentioned in my response to Bertrand which seems like a significant performance issue. In any case, I don't agree that the workspace name should be part of the resource tree. At that point, the workspace is essentially just a top-level node. When using workspaces for branching content/scripts/etc. it seems to make more sense to have the workspace name derived from something outside of the path. For example, if you think about how Google App Engine allows you to reference arbitrary versions of your application with a host name like version.appname.appspot.com (IIRC), one could imagine using the host header to select the workspace which corresponds to the requested version (and according to David's Model, this is a totally valid use of workspaces). Justin > > Carsten
Re: multi-workspace support in script resolution
Hi, On Wed, Mar 17, 2010 at 1:55 PM, Justin Edelson wrote: > On 3/17/10 4:31 AM, Bertrand Delacretaz wrote: >> ...Assuming you use workspaces for multi-homed websites, one could >> imagine having a "generic scripts" workspace where the script >> resolution would look after looking in the current resource's >> workspace. > I'm actually thinking almost the opposite - I clone a script from the > default workspace and edit it in a private workspace. I need to be able > to "preview" that modified script before pushing it back to the default > workspace... I think we mean the same thing: scripts in the private workspace, if present, override scripts in the default one, in the same way as currently scripts under /apps override those under /libs. -Bertrand
Re: multi-workspace support in script resolution
On 3/17/10 4:31 AM, Bertrand Delacretaz wrote: > Hi, > > On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson > wrote: >> Currently, although it's possible to log into different workspaces via >> AuthenticationInfo (even if httpauth and formauth don't support this); >> script resolution only happens against the default workspace. I don't >> see any reason for this restriction - it seems to me you should resolve >> scripts from the same workspace as the one resource was resolved from. >> WDYT?... > > In general yes, thought it might be interesting to fallback to another > workspace? This makes sense. > Assuming you use workspaces for multi-homed websites, one could > imagine having a "generic scripts" workspace where the script > resolution would look after looking in the current resource's > workspace. I'm actually thinking almost the opposite - I clone a script from the default workspace and edit it in a private workspace. I need to be able to "preview" that modified script before pushing it back to the default workspace. Ironically, as things currently stand I can do this with regular resource resolution, but not script resolution. > That might complicate things and/or cause performance issues > though...just thinking that it might be a valid use case, so just > having hooks for that might be good enough for now. The only performance issue I see is that the workspace name needs to be part of the cache key, which makes the cache keys larger and the cache itself potentially larger. Justin > > -Bertrand
Re: multi-workspace support in script resolution
Alexander Klimetschek wrote > The question for one workspace per account / user / etc. pops up every > now and then on the jackrabbit mailing lists and the general answer is > to try to stay away from that as it just complicates things: why > having to work with multiple workspaces when you can just create > separate nodes? Workspaces are technically meant for > branching/cloning/merging in the JCR spec. > > Hence support for multiple workspaces in Sling should IMHO not change > URL resolution at all (workspace as part of URLs) and should default > to expecting a single workspace (as now). If people want to use > multiple workspaces, tinkering would be required and they should be > able to plug in different resource resolvers / authentication > mechanisms that might select a different workspace for each request > depending on some request headers etc. But this should not be a > primary feature and shouldn't lead to complication of the Sling > architecture, I think. > Not sure if this is really about a workspace per user - anyways, mounting different workspaces in the resource tree does not complicate the architecture; it's something Sling is designed for :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
The question for one workspace per account / user / etc. pops up every now and then on the jackrabbit mailing lists and the general answer is to try to stay away from that as it just complicates things: why having to work with multiple workspaces when you can just create separate nodes? Workspaces are technically meant for branching/cloning/merging in the JCR spec. Hence support for multiple workspaces in Sling should IMHO not change URL resolution at all (workspace as part of URLs) and should default to expecting a single workspace (as now). If people want to use multiple workspaces, tinkering would be required and they should be able to plug in different resource resolvers / authentication mechanisms that might select a different workspace for each request depending on some request headers etc. But this should not be a primary feature and shouldn't lead to complication of the Sling architecture, I think. Just my 2 euro-cents... Regards, Alex On Wed, Mar 17, 2010 at 10:11, Carsten Ziegeler wrote: > Bertrand Delacretaz wrote >> Hi, >> >> On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler >> wrote: >>> ...In general I am not sure if it should be the authentication which >>> defines what workspace is used. I rather could picture having a resource >>> tree where workspaces are mounted at different locations in the tree. >>> The script resolution could then be configured to search in the various >>> workspaces >> >> I agree that this seems more logical than authentication switching >> workspaces - but not sure how to retrofit this, as IIUC the current >> tree does not consider workspaces. >> > It's right that the current implementation does not support this - but this > is something we have on our plate for a long time now and with the > change to the resource resolver factory - we started recently - we are > close to this. > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: multi-workspace support in script resolution
Bertrand Delacretaz wrote > Hi, > > On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler > wrote: >> ...In general I am not sure if it should be the authentication which >> defines what workspace is used. I rather could picture having a resource >> tree where workspaces are mounted at different locations in the tree. >> The script resolution could then be configured to search in the various >> workspaces > > I agree that this seems more logical than authentication switching > workspaces - but not sure how to retrofit this, as IIUC the current > tree does not consider workspaces. > It's right that the current implementation does not support this - but this is something we have on our plate for a long time now and with the change to the resource resolver factory - we started recently - we are close to this. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
Hi, On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler wrote: > ...In general I am not sure if it should be the authentication which > defines what workspace is used. I rather could picture having a resource > tree where workspaces are mounted at different locations in the tree. > The script resolution could then be configured to search in the various > workspaces I agree that this seems more logical than authentication switching workspaces - but not sure how to retrofit this, as IIUC the current tree does not consider workspaces. -Bertrand
Re: multi-workspace support in script resolution
Bertrand Delacretaz wrote > Hi, > > On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson > wrote: >> Currently, although it's possible to log into different workspaces via >> AuthenticationInfo (even if httpauth and formauth don't support this); >> script resolution only happens against the default workspace. I don't >> see any reason for this restriction - it seems to me you should resolve >> scripts from the same workspace as the one resource was resolved from. >> WDYT?... > > In general yes, thought it might be interesting to fallback to another > workspace? > > Assuming you use workspaces for multi-homed websites, one could > imagine having a "generic scripts" workspace where the script > resolution would look after looking in the current resource's > workspace. > > That might complicate things and/or cause performance issues > though...just thinking that it might be a valid use case, so just > having hooks for that might be good enough for now. > I'm not sure what the best way is, but Sling is resource tree based. The resource resolver (factory) gets configured with resource search paths (/apps and /libs is default) for scripts. The script resolver uses these paths to search for scripts. The script resolver uses an own session and therefore resource resolver which is not related to the current request. This allows a more secure installation as the current user does not have to have read rights for the scripts (or any other access rights). In general I am not sure if it should be the authentication which defines what workspace is used. I rather could picture having a resource tree where workspaces are mounted at different locations in the tree. The script resolution could then be configured to search in the various workspaces. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: multi-workspace support in script resolution
Hi, On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson wrote: > Currently, although it's possible to log into different workspaces via > AuthenticationInfo (even if httpauth and formauth don't support this); > script resolution only happens against the default workspace. I don't > see any reason for this restriction - it seems to me you should resolve > scripts from the same workspace as the one resource was resolved from. > WDYT?... In general yes, thought it might be interesting to fallback to another workspace? Assuming you use workspaces for multi-homed websites, one could imagine having a "generic scripts" workspace where the script resolution would look after looking in the current resource's workspace. That might complicate things and/or cause performance issues though...just thinking that it might be a valid use case, so just having hooks for that might be good enough for now. -Bertrand
multi-workspace support in script resolution
Currently, although it's possible to log into different workspaces via AuthenticationInfo (even if httpauth and formauth don't support this); script resolution only happens against the default workspace. I don't see any reason for this restriction - it seems to me you should resolve scripts from the same workspace as the one resource was resolved from. WDYT? I think I've resolved this locally (still testing), but wanted to get some feedback before committing it. Thanks, Justin
