Re: multi-workspace support in script resolution

[Justin Edelson]

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

[Justin Edelson]

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

[Felix Meschberger]

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 
 justinedel...@gmail.comwrote:
 
 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

[David Nuescheler]

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

[Justin Edelson]

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 
 justinedel...@gmail.comwrote:

 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

[Carsten Ziegeler]

Alexander Klimetschek  wrote
 On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler cziege...@apache.org 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

[Justin Edelson]

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

[Bertrand Delacretaz]

Hi,

On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com 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

Re: multi-workspace support in script resolution

[Carsten Ziegeler]

Bertrand Delacretaz  wrote
 Hi,
 
 On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com 
 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

[Bertrand Delacretaz]

Hi,

On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org 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

[Carsten Ziegeler]

Bertrand Delacretaz  wrote
 Hi,
 
 On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org 
 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

[Alexander Klimetschek]

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 cziege...@apache.org wrote:
 Bertrand Delacretaz  wrote
 Hi,

 On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org 
 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

[Carsten Ziegeler]

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

[Justin Edelson]

On 3/17/10 4:31 AM, Bertrand Delacretaz wrote:
 Hi,
 
 On Wed, Mar 17, 2010 at 2:45 AM, Justin Edelson justinedel...@gmail.com 
 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

[Bertrand Delacretaz]

Hi,

On Wed, Mar 17, 2010 at 1:55 PM, Justin Edelson justinedel...@gmail.com 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

[Justin Edelson]

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

[Justin Edelson]

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 cziege...@apache.org wrote:
 Bertrand Delacretaz  wrote
 Hi,

 On Wed, Mar 17, 2010 at 9:41 AM, Carsten Ziegeler cziege...@apache.org 
 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

[Bertrand Delacretaz]

On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson justinedel...@gmail.com 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

[Justin Edelson]

On 3/17/10 9:20 AM, Bertrand Delacretaz wrote:
 On Wed, Mar 17, 2010 at 2:08 PM, Justin Edelson
justinedel...@gmail.com 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

[Felix Meschberger]

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
 justinedel...@gmail.com 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

[Felix Meschberger]

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

[Justin Edelson]

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

[Felix Meschberger]

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

[Csákány Róbert]

+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 justinedel...@gmail.com 
 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

[Justin Edelson]

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

[Felix Meschberger]

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 codeHost/code
 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

[Justin Edelson]

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 codeHost/code
  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

[Justin Edelson]

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

[Felix Meschberger]

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

[Justin Edelson]

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

[Carsten Ziegeler]

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

[Justin Edelson]

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]

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

[Alexander Klimetschek]

On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler cziege...@apache.org 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

multi-workspace support in script resolution

[Justin Edelson]

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