jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Workspace name and code was: ORM-based persistence contrib build problems
Date Mon, 13 Jun 2005 17:04:00 GMT

Hi all,

Still thinking about this implementation, I think I found a small 
limitation in the current implementation. If I create a "code" for a 
workspace name, and let's say a new workspace is created using the 
Workspace.createWorkspace or Session.createWorkspace methods, I will 
then associate a new code with the new workspace. Up to there all is 
fine. Now it seems that Jackrabbit does not (yet?) manage the full 
lifecycle of workspaces, or I haven't been able to find methods that 
delete workspaces. The problem is that the PM should be notified of 
this, otherwise there will be left-over data in the back-end. As far as 
I could tell this problem would also arise with Filesystem-based PMs.

For the moment, if I understand this correctly, in the default 
implementation and configuration, new workspaces will be created in the 
repository/ directory. When using FS-based implementation, deleting a 
workspace is trivial, you could simply shutdown Jackrabbit, delete the 
workspace directory and all would be well (from what I read we might 
also be able to "dispose" of a workspace, but I don't know if this is 
correct) and then remove the files. Of course this is a bit manual and 
not ideal for scenarios where the repository must have good uptimes.

In the case of a "disconnected" back-end such as a database, this 
operation has to be done through the PM.

I should emphasis that I know this is not part of JCR, I'm only looking 
at this from a Jackrabbit point of view. The other interim solution 
would simply to let the data rot in the DB, in a disconnected state, but 
that's not ideal either. The one nice thing about using different 
database schemas mapped to workspaces is that disposing of a workspace 
is easily done by a DB admin, but there is no SQL standard for managing 

Any corrections/input on this would be more than welcome !

  Serge Huber.

Edgar Poce wrote:

>>Hmm... I'm having another problem now. You suggested the use of a param
>>to set the name of the workspace. From the PM, how do I access this ? In
>>the PMContext class I only have accessors to things like the HomeDir,
>>FileSystem, NameSpaceRegistry, NodeTypeRegistry and RootNodeUUID. I
>>didn't see anything related to parameters. Has this been removed in the
>>current code ? Or are the settings set through setter and reflection API ?
>It uses javabean convention, see
>>  Serge Huber.

View raw message