[MAGNOLIA-1659] always register repositories, nodetypes and workspaces from module definitions Created: 06/Aug/07  Updated: 23/Jan/13  Resolved: 27/Oct/07

Status: Closed
Project: Magnolia
Component/s: updatemechanism
Affects Version/s: 3.1 M1
Fix Version/s: 3.5 RC1

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-1602 Update mechanism Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

(related to the new update mechanism, MAGNOLIA-1602 )

at this moment the registration of new workspaces (also repositories/nodetypes) only happens during bootstrap and it's implemented by rewriting the repositories.xml file that will be loaded at system restart.
This should not be needed, we have all the APIs we need to register new repositories/workspaces without changing such xml file...

I propose to change the current implementation by making repositories declared in the module definition always checked. These are the steps that should be always performed while loading a module:

  • check if a declared repository exists -> if not create/load it in memory with default values (as it happens now on the repositories.xml file)
  • check if nodetypes already exist -> if not create them (better than now, this will auto-fix repositories where the nodetype definition is wrong/not complete)
  • check if workspace exists -> if not create it

I see several benefits in doing it this way: no restart needed, cleaner implementation and removal of the last bit that still rewrite a user configuration file. It should not have any drawback (if you want to tune your configuration you can still add a repository/workspace configuration to repositories.xml as before)



 Comments   
Comment by Fabrizio Giustina [ 11/Aug/07 ]

first draft in svn:
now repositories, workspaces and nodetypes are loaded directly from the definition in module's xml, without having to modify repositories.xml anymore.
All the setup is performed in ModuleManagerImpl, the previous methods in ModuleUtil have been deprecated and don't do anything now (a warn is logged).

Repositories/workspaces/nodetypes needs to be loaded always at startup; if modules need to be installed/updated this is also the firts step to be done.
For this reason this step is NOT performed as an update task but it's managed internally by ModuleManager. Everything is done in the method loadRepositories().
At this moment the logic is:

  • if there are no modules that need install or update
    -> load repositories directly in checkForInstallOrUpdates()
  • if updates are needed
    -> load repositories in performInstallOrUpdate()

this means that the creation of repositories is only performed after the user confirmation during an update, and also speedup the loading of magnolia itself. The repository loading in checkForInstallOrUpdates()() could not look so nice, but the only alternative solution is to add another public method/phase that should be called by the config loader.

Note also that:

  • the existing repository registration task have been renamed: now it only perform the initial bootstrap of empty workspaces and assigns permissions to the the superuser role (those tasks were already there, after workspace registration
  • nodetypes are always manually checked/registered, this should improve the consistency of repositories
  • when you remove a module their repositories are automatically discarded (not loaded anymore)... now it's a lot easier to remove a module, you don't have to manually rollback the repositories.xml file anymore

ready for feedbak

Comment by Philipp Bracher [ 14/Aug/07 ]

Goes definitely into the right direction.

> but the only alternative solution is to add another public method/phase that should be called by the config loader.

I think we should choose this way to keep the startup process clean

Comment by Fabrizio Giustina [ 27/Oct/07 ]

This already done for 3.1

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