>So far, no one needed it, as the implementation which is used today does >not support it.
well, depends which implementation is referenced - in the wcm.io Config property-level merging for parameter inheritance is supported. i agree with the arguments from justin and georg, and see more usecases where property-level merging is helpful than where it is harmful. keep in mind that content-aware configuration is often outside the scope of the devops-controlled automated configuration. in our usecases (worldwide-distributed marketing websites) we often have a big number of "business parameters" that control features on the websites which are switched on and off be editors using a graphical configuration editor within their CMS GUI. the devops team only maintains a sensible set of global/default confgurations which can be overridden by each of the hundreds of websites. without property merging a new parameter in a global/default configuration would mean to adjust hundreds of inherited configuration objects as well. in wcm.io config we also added support to "lock" a single configuration property on a certain context level, e.g. this allows to define a global or region-wide parameter and disallows the editors in the website to override it. useful e.g. to switch off a feature centrally which is currently malfunctioning until the application is fixed, and then the lock is removed again preserving the previous configuration state in each site. if we support object merging we already open "pandora's box" - if it is feared that property-level inheritance can do harm, the same can apply to object-level inheritance as well. we also have a third special case in inheritance: object/resource collection inheritance (object/resource collections are comparable to osgi factory configurations). we need to decide what happens when globally there are objects A and B in the config collection, and local there is C. is the result A+B+C or only C? some of the existing configuration solutions already support special properties to decide what is happening, because there are usecases for both results. the resource merger also has concepts for this. this usecase is currently missing in ians specification draft https://gist.github.com/ieb/460504e79c861cb980f4f0154210a869 in my pov it is not always correct the have the analogy of osgi configuration vs. context-aware configuration when deciding if thinks like property merging are useful or not - osgi configuration is per definition always global, never tenant-specific, never depending on context e.g. content tree, never hierarchical. this makes the usecases for inheritance and property merging more complex for context-aware configuration than for osgi configurations. perhaps we find a way to support both ways with the pluggable architecture i've in mind and that in good parts is already in use in wcm.io - activate the property-level merging osgi service or bundle if you want you want to use it, or leave it out if not. stefan
