one thought i had when implementing SLING-6059 and SLING-6058 (resource and property inheritance):
- currently both inheritance variants are switched off by default - they can be switched on by setting a special inherit property in the configuration resource - this property can either be set on the "inner-most" configuration resource matching the configuration path, or on anyone of the "outer" configuration levels up to the fallback path in /conf/global, /apps/conf, /libs/conf. - thus it is possible to enable resource and/or property inheritance by default for specific configuration names and keep it disabled for others. and it is possible to "break inheritance" on any level if enabled globally. all this flexible is not too complex to implement, but it comes at a cost: for each configuration resource the whole configuration inheritance hierarchy has to be searched for this special property if it is set to true. if yes, the inheritance takes place. checking for the property is a cheap operations, but still it leads to several additional resource accesses. if we would remove the feature to allow this property to be set on any hierarchy level, and only check for it on the last/inner-most configuration level this it would be more performant to implement. but it would reduce the features (no inheritance for all lower levels, no breaking of inheritance), which would make it less flexible. the problem is that even if the inheritance is never switched on anywhere, still all the whole inheritance tree has to be checked. do we think this is a performance problem? stefan
