You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Andreas Hartmann <an...@apache.org> on 2008/06/26 16:21:52 UTC
Multiple workspaces supported?
Hi Sling devs,
is it possible to access multiple JCR workspaces via a Sling
application? The WebDAV-related documentation mentiones a URL prefix,
but I couldn't find a corresponding URL syntax in the request processing
documentation …
TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: Authoring/Staging/Live
Posted by Andreas Hartmann <an...@apache.org>.
Hi Felix and Tobias,
thanks for your answers! I'm taking this to user@jackrabbit since it's
quite OT for Sling.
-- Andreas
Tobias Bocanegra schrieb:
> On 6/27/08, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi Andreas,
>>
>> I also consider the "separate workspaces" approach best. In particular it
>> lends hand to an extended solution if you decide to complete separate author
>> and staging, where you have two distinct repositories and replicate data
>> from author to staging.
>>
>> Access Control handling depends on the JCR repository implementation.
>> JSR-170 (JCR 1.0) does not have any standardized ACL (except a single call
>> to check for access). JSR-283 (JCR 2.0) will bring standardized ACL. Still,
>> how this is implemented remains - of course - unspecified.
>>
>> IIRC the approach taken in Jackrabbit is to attach ACL child nodes to the
>> nodes to which access control is applied. So if you replicate (workspace
>> update, cross-repository replication) any node (or subtree) and include the
>> ACL child nodes in the replication, you get the same access control on both
>> sides.
> in an upcomming version of jackrabbit that will implement some
> features of the to-be-released JSR283 spec, there will also be a
> user-based hierarchical access control. this usually suits better for
> CMS application, since CMS authors are usually authorized to maintain
> one subtree of the site.
> that hierarchical user-based ACLs will be stored per-workspace, i.e.
> if copying a node to another workspace, the same user can have
> different ACLs. This makes sense, since a content author might not be
> allowed to alter content on the staging or even the live workspace.
> with a document-based ACLs you would need to remove/alter them
> 'manually' when copying them to another workspace. however, this might
> not be a big problem, if you define some ACLs on the respective parent
> nodes, because the privileges get inherited to the child nodes.
>
> regards, toby
>> For the workspace update mechanism, you don't have to care for the user
>> setup as users are stored repository-wide in the system workspace. For a
>> cross-repository replication you have to take care that the user base
>> matches on both repositories, of course.
>>
>> Hope this helps.
>>
>> Regards
>> Felix
>>
>>
>> Andreas Hartmann schrieb:
>>
>>> Hi Felix,
>>>
>>> > Andreas Hartmann schrieb:
>>> >> is it possible to access multiple JCR workspaces via a
>>> >> Sling application?
>>> >
>>> > Basically yes. Your application may grab the Repository (or
>>> > SlingRepository) service from the service registry and login to the
>>> > repository specifying different workspaces to access.
>>>
>>> thanks for your answer, it's good to know that accessing multiple
>> workspaces is possible.
>>> I'd be interested in your opinions about the correct approach to a staging
>> environment like it is provided by traditional CMS applications. I see the
>> following options:
>>> Separate workspaces
>>> ===================
>>> * Corresponding nodes with same UUID possible
>>> * Updating nodes/subtrees possible
>>> * Question: How are access control settings handled?
>>>
>>> Separate areas in a single workspace
>>> ====================================
>>> * No corresponding nodes with same UUID possible
>>> * Maintaining access control definitions could be complicated
>>> * Updating nodes/subtrees has to be implemented
>>>
>>> Separate areas as child nodes
>>> =============================
>>> * Areas not self-contained
>>> * No direct URI-to-path mapping possible
>>>
>>> Labelled versions
>>> =================
>>> * Changes applied immediately, without calling Session.save()
>>> (might be a problem wrt transactions)
>>> * Access control to version history has to be considered
>>>
>>>
>>> My gut feeling tells me that separate workspaces are the most promising
>> approach. But I don't know how the access control settings (in this case,
>> permissions to change properties of particular nodes) are maintained across
>> workspaces. Would they have to be kept in sync manually?
>>> Is there a general best practise to model this kind of functionality?
>>>
>>> Thanks a lot in advance for any hints!
>>>
>>> -- Andreas
>>>
>>>
>>>
>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: Authoring/Staging/Live
Posted by Tobias Bocanegra <to...@day.com>.
On 6/27/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi Andreas,
>
> I also consider the "separate workspaces" approach best. In particular it
> lends hand to an extended solution if you decide to complete separate author
> and staging, where you have two distinct repositories and replicate data
> from author to staging.
>
> Access Control handling depends on the JCR repository implementation.
> JSR-170 (JCR 1.0) does not have any standardized ACL (except a single call
> to check for access). JSR-283 (JCR 2.0) will bring standardized ACL. Still,
> how this is implemented remains - of course - unspecified.
>
> IIRC the approach taken in Jackrabbit is to attach ACL child nodes to the
> nodes to which access control is applied. So if you replicate (workspace
> update, cross-repository replication) any node (or subtree) and include the
> ACL child nodes in the replication, you get the same access control on both
> sides.
in an upcomming version of jackrabbit that will implement some
features of the to-be-released JSR283 spec, there will also be a
user-based hierarchical access control. this usually suits better for
CMS application, since CMS authors are usually authorized to maintain
one subtree of the site.
that hierarchical user-based ACLs will be stored per-workspace, i.e.
if copying a node to another workspace, the same user can have
different ACLs. This makes sense, since a content author might not be
allowed to alter content on the staging or even the live workspace.
with a document-based ACLs you would need to remove/alter them
'manually' when copying them to another workspace. however, this might
not be a big problem, if you define some ACLs on the respective parent
nodes, because the privileges get inherited to the child nodes.
regards, toby
>
> For the workspace update mechanism, you don't have to care for the user
> setup as users are stored repository-wide in the system workspace. For a
> cross-repository replication you have to take care that the user base
> matches on both repositories, of course.
>
> Hope this helps.
>
> Regards
> Felix
>
>
> Andreas Hartmann schrieb:
>
> > Hi Felix,
> >
> > > Andreas Hartmann schrieb:
> > >> is it possible to access multiple JCR workspaces via a
> > >> Sling application?
> > >
> > > Basically yes. Your application may grab the Repository (or
> > > SlingRepository) service from the service registry and login to the
> > > repository specifying different workspaces to access.
> >
> > thanks for your answer, it's good to know that accessing multiple
> workspaces is possible.
> >
> > I'd be interested in your opinions about the correct approach to a staging
> environment like it is provided by traditional CMS applications. I see the
> following options:
> >
> > Separate workspaces
> > ===================
> > * Corresponding nodes with same UUID possible
> > * Updating nodes/subtrees possible
> > * Question: How are access control settings handled?
> >
> > Separate areas in a single workspace
> > ====================================
> > * No corresponding nodes with same UUID possible
> > * Maintaining access control definitions could be complicated
> > * Updating nodes/subtrees has to be implemented
> >
> > Separate areas as child nodes
> > =============================
> > * Areas not self-contained
> > * No direct URI-to-path mapping possible
> >
> > Labelled versions
> > =================
> > * Changes applied immediately, without calling Session.save()
> > (might be a problem wrt transactions)
> > * Access control to version history has to be considered
> >
> >
> > My gut feeling tells me that separate workspaces are the most promising
> approach. But I don't know how the access control settings (in this case,
> permissions to change properties of particular nodes) are maintained across
> workspaces. Would they have to be kept in sync manually?
> >
> > Is there a general best practise to model this kind of functionality?
> >
> > Thanks a lot in advance for any hints!
> >
> > -- Andreas
> >
> >
> >
>
Re: Authoring/Staging/Live
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Andreas,
I also consider the "separate workspaces" approach best. In particular
it lends hand to an extended solution if you decide to complete separate
author and staging, where you have two distinct repositories and
replicate data from author to staging.
Access Control handling depends on the JCR repository implementation.
JSR-170 (JCR 1.0) does not have any standardized ACL (except a single
call to check for access). JSR-283 (JCR 2.0) will bring standardized
ACL. Still, how this is implemented remains - of course - unspecified.
IIRC the approach taken in Jackrabbit is to attach ACL child nodes to
the nodes to which access control is applied. So if you replicate
(workspace update, cross-repository replication) any node (or subtree)
and include the ACL child nodes in the replication, you get the same
access control on both sides.
For the workspace update mechanism, you don't have to care for the user
setup as users are stored repository-wide in the system workspace. For a
cross-repository replication you have to take care that the user base
matches on both repositories, of course.
Hope this helps.
Regards
Felix
Andreas Hartmann schrieb:
> Hi Felix,
>
> > Andreas Hartmann schrieb:
> >> is it possible to access multiple JCR workspaces via a
> >> Sling application?
> >
> > Basically yes. Your application may grab the Repository (or
> > SlingRepository) service from the service registry and login to the
> > repository specifying different workspaces to access.
>
> thanks for your answer, it's good to know that accessing multiple
> workspaces is possible.
>
> I'd be interested in your opinions about the correct approach to a
> staging environment like it is provided by traditional CMS applications.
> I see the following options:
>
> Separate workspaces
> ===================
> * Corresponding nodes with same UUID possible
> * Updating nodes/subtrees possible
> * Question: How are access control settings handled?
>
> Separate areas in a single workspace
> ====================================
> * No corresponding nodes with same UUID possible
> * Maintaining access control definitions could be complicated
> * Updating nodes/subtrees has to be implemented
>
> Separate areas as child nodes
> =============================
> * Areas not self-contained
> * No direct URI-to-path mapping possible
>
> Labelled versions
> =================
> * Changes applied immediately, without calling Session.save()
> (might be a problem wrt transactions)
> * Access control to version history has to be considered
>
>
> My gut feeling tells me that separate workspaces are the most promising
> approach. But I don't know how the access control settings (in this
> case, permissions to change properties of particular nodes) are
> maintained across workspaces. Would they have to be kept in sync manually?
>
> Is there a general best practise to model this kind of functionality?
>
> Thanks a lot in advance for any hints!
>
> -- Andreas
>
>
Authoring/Staging/Live (was: Multiple workspaces supported?)
Posted by Andreas Hartmann <an...@apache.org>.
Hi Felix,
> Andreas Hartmann schrieb:
>> is it possible to access multiple JCR workspaces via a
>> Sling application?
>
> Basically yes. Your application may grab the Repository (or
> SlingRepository) service from the service registry and login to the
> repository specifying different workspaces to access.
thanks for your answer, it's good to know that accessing multiple
workspaces is possible.
I'd be interested in your opinions about the correct approach to a
staging environment like it is provided by traditional CMS applications.
I see the following options:
Separate workspaces
===================
* Corresponding nodes with same UUID possible
* Updating nodes/subtrees possible
* Question: How are access control settings handled?
Separate areas in a single workspace
====================================
* No corresponding nodes with same UUID possible
* Maintaining access control definitions could be complicated
* Updating nodes/subtrees has to be implemented
Separate areas as child nodes
=============================
* Areas not self-contained
* No direct URI-to-path mapping possible
Labelled versions
=================
* Changes applied immediately, without calling Session.save()
(might be a problem wrt transactions)
* Access control to version history has to be considered
My gut feeling tells me that separate workspaces are the most promising
approach. But I don't know how the access control settings (in this
case, permissions to change properties of particular nodes) are
maintained across workspaces. Would they have to be kept in sync manually?
Is there a general best practise to model this kind of functionality?
Thanks a lot in advance for any hints!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: Multiple workspaces supported?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Andreas,
Andreas Hartmann schrieb:
> Hi Sling devs,
>
> is it possible to access multiple JCR workspaces via a Sling
> application?
Basically yes. Your application may grab the Repository (or
SlingRepository) service from the service registry and login to the
repository specifying different workspaces to access.
You may also create a ResourceResolver around such sessions to make use
of the ResourceResolver mechanism.
Out of the box, though, Sling itself (internally by means of the
SlingHttpServletRequest) accesses only a single workspace. This
particularly is the case for the resolution of the resource addressed by
the request URL and the resolution of the script to handel the request.
The WebDAV-related documentation mentiones a URL prefix,
> but I couldn't find a corresponding URL syntax in the request processing
> documentation …
There is no such prefix (right now) because Sling itself only accesses a
single workspace.
Hope this helps.
Regards
Felix