done. https://issues.apache.org/jira/browse/JCR-1677
-Matej On Mon, Jul 14, 2008 at 4:04 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Well, if the change is not that dramatically and would be enabled via > an explicit configuration (like <Cluster createWorkspaces="true" />), > I think it could be integrated into Jackrabbit. Could you create a > JIRA issue for this [1] and upload your patch? The team could then > discuss this patch for 1.5. > > [1] https://issues.apache.org/jira/secure/CreateIssue!default.jspa > > Thanks, > Alex > > On Mon, Jul 14, 2008 at 1:20 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: >> That is a very inconvenient limitation. We are using workspaces for >> snapshots, publishing states and possibly for language versions. None >> of these we know upfront. Workspaces give us the possibility to match >> nodes with same UUID, something we wouldn't be able to do with >> top-level structure. I think the usecase is quite reasonable, the only >> limitation is workspace creation not being accepted on other nodes. >> >> This seems quite arbitrary to me though. I don't think we're the only >> ones depending on runtime workspace creation. >> >> Now it is possible to get workspace creation across cluster, however >> it requires me to subclass RepositoryImpl and ClusterNode which in >> turn requires me to touch package protected classes and it seems quite >> hacky. Is there any chance there would be at least a system property >> introduced in 1.5 that would force creation of the appropriate >> workspace when the workspace is first time encountered in >> ClusterNode#process (or other appropriate places)? >> >> Kind regards, >> Matej Knopp >> >> On Mon, Jul 14, 2008 at 12:22 PM, Alexander Klimetschek >> <[EMAIL PROTECTED]> wrote: >>> Hi Matej, >>> >>> this is normal. Clustering expects the same setup on all nodes - and >>> the workspaces are a part of them. >>> >>> Why do you have so many workspaces? It sounds like you might be better >>> off by organizing your content model into a top-level structure inside >>> one workspace. The number of workspaces should IMHO not depend on >>> "input-data", like requests or content of imported data. Otherwise you >>> can make your application code create all the necessary workspaces on >>> startup - this is the typical way to do it. >>> >>> Regards, >>> Alex >>> >>> On Sun, Jul 13, 2008 at 1:28 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: >>>> Hi, >>>> >>>> I have the following problem when running jackrabbit in clustered >>>> environment. When I create workspace on cluster node A and then add a >>>> node to that workspace, the proper event is sent to the journal, but >>>> other cluster nodes are not able to process it because they don't have >>>> the workspace. >>>> >>>> I did manage to intercept the this making the other nodes create the >>>> workspace (subclassing ClusterNode, peeking in the record inside >>>> #consume and creating the workspace there) but is it really necessary >>>> to have to go over all these hoops? Couldn't be there way (at east an >>>> option) to create workspace any time a node is being added to that >>>> workspace for cluster nodes that don't have the workspace yet? >>>> >>>> Kind regards, >>>> Matej Knopp >>>> >>> >>> >>> >>> -- >>> Alexander Klimetschek >>> [EMAIL PROTECTED] >>> >> > > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
