[MAGNOLIA-843] OpenWFE module should register workspaces under magnolia repository Created: 11/May/06  Updated: 23/Jan/13  Resolved: 29/May/06

Status: Closed
Project: Magnolia
Component/s: workflow
Affects Version/s: 3.0 Beta 1
Fix Version/s: 3.0 RC1

Type: Task Priority: Minor
Reporter: Sameer Charles Assignee: Nicolas Modrzyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoR:
Empty

 Description   

We should try to use workspaces for all modules instead of initializing separate repository.



 Comments   
Comment by Sameer Charles [ 17/May/06 ]

I had a quick look at the module utils and I did not liked the fact that there are different places where repositories/workspaces/nodeTypes are registered.
module registration should "only" update repositories.xml and rest is taken care on loading.

yes you are right jackrabbit maintain nodetypes per repository, but still in magnolia repositories.xml we can add this property to workspace instead
which will simply append these node types to the existing once for this repository
We have to make sure that workspace custom nodetype files should not overwrite any magnolia specific node types.

Comment by Sameer Charles [ 17/May/06 ]

Module Registration and Module loading is mixed together.
so half of the repository initialization is done before modules are loaded and rest is done on module loading, but from next restart
everything is done at once.

I would like to separate module registration (part where module registers itself based on META_INF/*) and module loading which is independednt of the repository/workspace initialization.

It should be something like:
1. Webapp startup
2. Module registration (if any new modules found)
3. ContentRepository initlialization
4. all modules initialization and server setup

what you gyus think?

if module has special node types it will be written anyways in repositories.xml and taken care of on Step-3

Generated at Mon Feb 12 03:21:11 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.