-
Improvement
-
Resolution: Fixed
-
Neutral
-
5.4.5
-
None
-
None
-
-
Empty show more show less
-
Basel 43
-
3
Module descriptors have the ability to define configuration-properties read by the system and exposed by info.magnolia.init.MagnoliaConfigurationProperties.
They get loaded during startup in MagnoliaContextServerListener right after loading the module descriptors from the class path.
By Introducing light-module-descriptors read from the resources-directory defined in magnolia.properties we introduce a circular dependency between module-descriptor loading and properties-loading. Light-modules are dependent on the magnolia configuration properties being present, to obtain the resources-path and the configuration properties are dependent on the module descriptors being present.
There are several approaches to fix this:
- Lazy-loading the module-descriptor sources
- Split the DefaultMagnoliaConfigurationProperties into a implementation used during startup and a complete one holding the module descriptor provided source at a later stage.
- Opening up info.magnolia.init.DefaultMagnoliaConfigurationProperties and allow registering property-sources ad-hoc
As DefaultMagnoliaConfigurationProperties already imposes an order in which the sources are "overriden" I tend to go for the lazy-loading mechanism. It's less invasive than introducing a second, stripped down implementation, which would need to re-order the sources somehow. OTOH the circular dependency conceptually remains.
This topic was discussed in Arch-meeting w/ mgeljic, apchelintcev and pmundt.
Update: Decision was made to go with the second approach. Introduced an info.magnolia.init.InitPhaseMagnoliaConfigurationProperties which loads the properties from info.magnolia.init.MagnoliaInitPaths and info.magnolia.init.MagnoliaPropertiesResolver. Bound to the platform-components. During startup the default implementation will be bound to the system-components by core-module.