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, Ryan "David Nuescheler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > hi ryan, > > On Apr 10, 2005 6:19 AM, Ryan Dewell <[EMAIL PROTECTED]> 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 >
