[MAGNOLIA-1373] User configuration should have priority on module default config when bootstrapping Created: 11/Feb/07  Updated: 23/Jan/13  Resolved: 28/Aug/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.0.1
Fix Version/s: 3.5 RC1

Type: Bug Priority: Blocker
Reporter: Fabrizio Giustina Assignee: Boris Kraft
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MAGNOLIA-1380 modules: modules should not bootstrap... Closed
relation
is related to MAGNOLIA-1353 bootstrapping: custom mime types are ... Closed
is related to MAGNOLIA-1706 Bootstrap of webapp is now fully and ... 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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The current bootstrapping sequence don't let users change many default values loaded by modules.

Bootstrap XML in modules is intended as a default, that should be loaded when no other configuration is found and that could be overwritten by specific configuration by users.
At this moment anyway modules configuration is loaded after user content in the bootstrap dir and overwrites any custom configuration. I have several use cases that were used to work with pre-3.0 builds and that now I can't make work with 3.0.1, such as:

  • adding custom mime-types: the whole server/MimeTypes tree is overwritten by the late bootstrap of the adminInterface and new mime types are deleted. This is also traced in MAGNOLIA-1353
  • changing cache configuration: the configuration in the cache module bootstrap is definitively just a default since you should be able to choose between different implementation. Also the cache filter in the server section should be overwritable (by supplying a custom extension). None of these configurations can now be changed at bootstrap, since at the end of the bootstrap you will always end up with the module defaults.

What about bootstrapping modules before loading xml files in the user bootstrap dir? Do anybody see problems with this or has an idea for a better solution?



 Comments   
Comment by Philipp Bracher [ 15/Feb/07 ]

The current code should

  • bootstrap all files in bootstrap dirs except those with prefix config.modules
  • each module is bootstrapped (default configuration)
  • after each module the config.modules.name files in the bootstrap dir are bootsrapped (custom configuration)

This allows to put custom module configuration into the default bootstrap dir.

Unfortunately there is a problem when a module bootstrap things in the server section. Here the module will overwrite what ever was bootsrapped before. For the mime types the bootsrap file should anyway not lay in the admin interface module. This can be solved by moving this configuration to the web apps bootstrap dir.

But cache configuration is bootstrap-able, except the filter (which is in server/filters again).

Modules should bootstrap the parts in config:server more savely.

Current workaround: make a custom module with a dependency --> your module is bootsrapped after the module you depend on)

Comment by Philipp Bracher [ 15/Feb/07 ]

If you agree, I will close this report and keep only the new report MAGNOLIA-1380

Comment by Magnolia International [ 02/Mar/07 ]

Fabrizio, I also thought bootstrapping modules before loading xml files in the user bootstrap dir could help, but that would be awkward for modules you install on an existing system (since those would be bootstrap "after" the webapp bootstrap directories, obviously), so depending on how/when the modules would be installed, you would get different reactions from the system.

I think generally the bootstrapping mechanism could use some cleaning up and simplification. Maybe adding stricter rules like "modules can only bootstrap content under their own node", although I'm sure you guys will come up with scenarios where this is not acceptable ..

Comment by Magnolia International [ 28/Aug/07 ]

fixed with MAGNOLIA-1706 and updatemechanism

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