*See inline...* 2014-12-27 11:42 GMT+01:00 Mark Struberg <[email protected]>:
> Hi! > > 1.1) > > I think we agree that having a PropertySource/ConfigSource SPI with MANY > implementations is the way to go? > Any objections? > *+1 The way to go.* 1.2) > > Where should it belong to? Is it an API or rather an SPI? > I think it's more the later. A end user just likes to get the 'final' > configured values and does NOT deal with the PropertySources himself. It is > really just for extending the system -> SPI. > *+1 for PropertySource being an SPI. Configuration must be the API.* 1.3) > Merging. > Option (1.3.a) Do we like to do 'implicit' merging (aka the ordinal > stuff). > *It's not a question of taste. The mechanism is clumsy and implies constraints that are already known as of now not matching all use cases. On top of it the priority leaks into the PropertySoiurce API (as an additional method, which is a very ugly mix of concerns), Finally functions is the modern way of modelling such an operation.* > Option (1.3.b) Or do we like 'explicit' (the merge function). What benefit > does this add in practice? > *See above and as outlined multiple times. Adding additional functionality for audit (e.g. logging of the configuration overriding), different or partial overridings (common in complex environments). Please stop discussion on this priority thing, it's simply not enough! By the way the priority thing can still be implemented, when the rest of the design is done in a modular way. My proposed solution gave you the abtrsaction of a ConfigProvider BTW, where you could do this easily, but also the other stuff. What you do depends on the use case, and to some extent your personal taste. A solution should NEVER constraint users in doing the stuff they want!* Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH > ConfigSource (PropertySource) has an ordinal which it can set itself. The > higher the configuration ordinal of the ConfigSource, the more important it > is and it will override values from ConfigSources with lower ordinal. > > That way it is possible to have a kind of 'default configuration' e.g. in > a property file inside your project and later overwrite it via -Dxxx=yyy, > JNDI, or some container provided MyCountainerAdminConfigSource etc later. > *No Mark. The fact of having a default configuration does not interconnect how this is evaluated and composed. You are wrong! And on top, when I look at your ideas: you will never get one solution, which a special type of overridings that matches all users. You have to provide building blocks (one more) that helps the users (companies) to model their functionality with it. You are not on green field here!* Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There was > merge(String key, PropertySource s1, s2), but that would mean that every > user needs to deal with that himself? Could you please elaborate on that > option? I didn't get it.. *Of course not! (despite the fact that is trivial for the ones used the functional style of Java 8). You can still provide a singleton with constants, where you* *provide the most common combinations, see AggregationPolicy in my the current tree.* *-Anatole* > > > LieGrue, > strub > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
