Hi everyone, I personally see a tooling based approach complicated due to the ownership scenarios. We are talking about context aware configuration that typically would be applied by some runtime user that might have limited write access (just for a specific context). The assumption that who writes to the inheriting configuration node also has write access to the subsequent levels is something we cannot and should not make here. I know multiple customer scenarios where a central site (including global configuration) was maintained by a central marketing organization while the markets owned their own sites - so they declare inheritance (pull) instead of having the global one pushed.
The one thing in between that I could imagine might work sufficiently is referencing (by path to property) instead of inheritance. This still provides the lookup of "inheritance" at runtime where changes are reflected in the lookup immediately but at the same time gets rid of magic inheritance rules. Just a thought about an alternative in between. Cheers Dominik On Mon, Aug 1, 2016 at 8:36 AM, Carsten Ziegeler <[email protected]> wrote: > >> ... if you have merging (or inheritance) then you change the > >> attribute of a parent and this influences all childs and you > >> have no idea what happens there... > > > > We can create a felix console plugin that shows for a given > > context path and config name the value of the property and the > > path from where it was taken - that way both developers and ops > > can quickly check what's going wrong if results are unexpected. > > > >> I personally think this comes all down to tooling ... > > > > So this could mean e.g. an additional maven plugin, which handles > > merging of configurations and then the runtime can work without > > merging. The problem I see with that is that > > * you end up having two similar configuration model types (one in > > the source code that supports merging and one effective one for > > the runtime) - this makes the mechanism harder to understand > > for everyone > > * the tooling has to be created and IMHO it'll not be easier/less > > code than creating a smarter runtime (even if we take into > > account that we have to create the felix console plugin to make > > it traceable) > > > First of all, you need tooling anyway. It would be foolish to make > these configurations without any tooling by hand. Tooling can easily > be customized to anyones needs without tampering the implementation. > The implementation at runtime can be simply and effective. > > We had similar discussions while starting the work for the OSGi > Configurator which allows you to put OSGi configurations into a bundle > which then get applied at runtime. My initial proposal had all the > things requested here as well (merging, inheritance etc.). It turned > out that this messed up the specification and made the implementation > extraordinary complicated. While moving this into the tooling which > creates the bundles in the first place solves all the problems. > > Just think of all the different cases you have to solve once you > start support merging. And not to mention the runtime implications as > you have to do the merging dynamically at runtime as well, or you > start introducing all kinds of caching again. All of this is not > required if you move this to the tooling level. > > Regards > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] > >
