So get into some details of real configuration solutions...
1. You may have property sets that have different priorities, but are in the same configuration source. 2. You may have certain entries from a domain/system config, that should never be overridable by users, whereas others are free to be adapted. 3. You max have certain entries that have different priorities not related to the configuration source, but related to an additional meta-info (per entry/area), which defines its own priorization mechanism. E.g. you may have global defaults, domain defaults, ear defaults, app defaults, explicit config related to ear, explicit for application, explicit for tier, server, network zone. 4. Additionally you want to define certain packages of configuration (may be from different sources, different files and even formats) where you imply certain checks for integrity and correctness, e.g. your domain configuration should throw an exception if you have conflicting entries, though the entries are read from different configuration sources. In that case overriding is not always the best solutions. I had some discussion with guys throughout the world that run very complex setups (Credit Suisse being one of them). Experience shows that the way configuration is organized is highly differing. I agree that organizing everything along priorities works in many cases, but unfortunately not in all IMO. Also I prefer to have a intuitive model that allows users to explicitly model their configuration (meta-model) building blocks, also having the possibility for abstraction (separation of concerns), which I think sets and set operations are more convenient that splitting everything up to sources and priorities. Since we talk about properties, viewing them as sets for me looks quite natural. Set operations on top are easy understood and also theoretical powerful enough to cover everything out there (do you have the same mathematical background your priorities based approach ? ). Also commons-config BTW has similar mechanisms in place. Agree? Cheers, Anatole Gerhard Petracek [email protected]> schrieb am Di., 2. Dez. 2014 um 23:27: hi @ all, > > @anatole: > please also add >real-world< examples to the document. > if we don't have/find them, we need to think about dropping concepts again. > > fyi: > configs in deltaspike get merged based on the key. > > e.g.: > config-source a (priority 1) > key1=x > > config-source b (priority 2) > key1=y > key2=z > > ConfigResolver.getPropertyValue("key1") leads to: x > ConfigResolver.getPropertyValue("key2") leads to: z > > imo mark introduced a nice and simple (but powerful) concept with that > (esp. since you can re-order even predefined config-source ordinals). > deltaspike also uses prefixes for "areas" (internally), but it was never > needed to introduce an own concept for that. > > regards, > gerhard > > > > 2014-12-02 14:35 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > Yes, it will. > > Am 02.12.14 14:19, schrieb Werner Keil: > > > >> Ok, so at least when generated into common output formats it won't > >> show?;-) > >> > >> > >> > >> > >> > > -- > > N Oliver B. Fischer > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > > P +49 30 44793251 > > M +49 178 7903538 > > E [email protected] > > S oliver.b.fischer > > J [email protected] > > X http://xing.to/obf > > > > >
