jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Dewell" <r...@dewell.org>
Subject Re: Workspaces
Date Sun, 10 Apr 2005 23:20:29 GMT
Hi David,

Thanks for the reply.  What I'm gathering from your post and re-reading the 
spec sections on workspaces is that the actual use of workspaces is more of 
an exotic case that is probably not applicable or desireable in my 
situation.  What it sounds like I want to do is use one workspace and 
implement my own security layer over the top of that to protect access to 
resources.  For example, to keep x:jane out of x:bob's stuff.  So, when 
either x:jane or x:bob logs in, they get the same workspaces with the same 
root, but their access to resources would be restricted.

>From a jackrabbit standpoint, it looks like that means implementing my own 
AccessManager.  Does anyone know if there is a good reason that the 
AMContext has no access to the current Session or Repository?  If I want to 
implement a security mechanism where the permission data is actually stored 
in the repository as well, it would be handy to have access to the 
Repository or Session from AccessManager.  Although, I guess there's no 
reason I couldn't get the same Repository instance from JNDI in my own 
AccessManager implementation.  Thinking out loud at this point...

Best regards,


"David Nuescheler" <david.nuescheler@gmail.com> wrote in message 
> hi ryan,
> On Apr 10, 2005 6:19 AM, Ryan Dewell <ryan@dewell.org> wrote:
>> Hi, I'm just diving into JR and so far so good.  I'm trying to understand
>> some concepts, though, related to workspaces and the repository as a 
>> whole.
>> Let's say I have a repository that looks like a file system with user
>> directories:
>> /jcr:root/x:users/x:jane/<STUFF>
>> /jcr:root/x:users/x:bob/<STUFF>
>> /jcr:root/x:system/<STUFF>
>> I originally expected to be able to obtain a Session that is rooted at
>> x:jane or x:bob, all from one global repository workspace.  But, what I'm
>> seeing right now (through sleepy eyes) is that I'd have to give x:jane 
>> and
>> x:bob different workspaces in repository.xml.  Is this correct?
> it is correct that if you completely want to separate those user
> directories (like a unix chroot) a workspace per user is one of the
> intented ways to achieve that in jcr.
>> If workspaces are the preferred (or only) way to get a Session rooted at 
>> a
>> particular Node, then I guess I'm looking for a way to dynamically create
>> workspaces at runtime without modifying repository.xml.  I see a
>> createWorkspace in RepositoryImpl, but it is package private.
>> Any ideas on this are appreciated.  I'm still wrapping my head around 
>> some
>> of this as you can tell.  :)
> workspace management has been identified as an
> administrational task and has been excluded from
> the jsr-170 v1.0 api (similar to for example nodetype
> creation and management)
> of course an implementation could (and in the case of
> jackrabbit "should") offer a simple call to create workspaces, and
> i think that the createWorkspace on WorkspaceImpl may be
> what you are looking for.
> [ http://www.google.com/search?q=jackrabbit+createWorkspace ;) ]
> ... but i guess so far we have not really structured an explicit "public"
> jackrabbit api, that deals with functionality that goes beyond
> jsr-170.
> does someone have a good suggestion how to solve that in general?
> regards,
> david

View raw message