> The mechanism is clumsy and implies > constraints that are already known as of now not matching all use cases.
Tell me some limitations. Never had one. So just enlist them here and now. > On top of it the priority leaks into the PropertySource API Because it IS part of the PropertySource! > Finally functions is the > modern way of modelling such an operation. If you have a hammer... I'm not interested in style if it doesn't add any real benefit. > different or > partial overridings (common in complex environments) Never came across this need and I did very complex projects. It's always a trade off between an easy straight forward algorigthm which are easy to understand but sometimes you have to bend em a bit or program your own (PropertySource). The other option is to have hugely complex base mechanism which noone can use in practice because it is 'too flexible' - means not clear and straight enough. > you will never get one solution, which a special type of > overridings that matches all users. Oh sure we do. By having the ConfigSource define their ordinal themselves and it being really easy for a programmer to add own ConfigSources we have all of that! > A solution should NEVER constraint users in doing the stuff > they want!* Having the sorting via Ordinal doesn't impose any restriction on the user. Because he can easily overwrite those values. We are talking about a simple straight forward config mechanism and not about alien rocket science and time travelling. >You are not on green field here! Oh boy, we are! We just need to fulfil user needs, that's all. > *Of course not! (despite the fact that is trivial for the ones used the > functional style of Java 8). Of course I know Map#merge, but what do you use it for? To me it seems like an overkill. > You can still provide a singleton with > constants, where you* > *provide the most common combinations, see AggregationPolicy in my the > current tree.* Again: I don't see the benefit. If I'm in an EAR and like to get my "documentarchive.endpoint.url" then WHY would I like to manually change the aggregation? Makes no sense to me. And this increases the complexity quite impressively. LieGrue, strub > On Saturday, 27 December 2014, 12:28, Anatole Tresch <[email protected]> > wrote: > > *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* >
