>> ... 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 cziege...@apache.org
