that's what we said at the beginning and think using current impl as default makes sense. Would be another SPI with a default "OrdinalMergePolicy" impl. I like this one cause then the implementation of the default properties property source can rely on it as well I think so makes things as smooth as today by default and still easy to follow if needed.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-23 13:01 GMT+01:00 Anatole Tresch <[email protected]>: > Basically an option to override the merge policy when accessing a value. > Applying a alternate merge policy to a full map only makes sense in a few > cases, similar to the fact that overriding is not always what you want. > Nevertheless I see currently 2 options: > 1) passing it when accessing a single value > 2) applying a merge policy to a full config. > > 2 has the advantage that we dont have to pollute the api, and that it works > transparently... > > Wdyt? > Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. 2015 um > 11:53: > >> you what you want is more a configurable merge policy than a >> collector, no? - just trying to identify the right level of the >> feature >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-23 11:49 GMT+01:00 Tresch, Anatole <anatole.tresch@credit-suisse. >> com>: >> > OK, but related to conversion: I am only interested in one single entry. >> The Map is still <String,String>, isn't it? >> > Do why should I extract the whole map to just access one single >> property. On top of that, as I mentioned, I want also >> > be able to collect all entries for a given key, instead of overriding >> them. This IMO is not solved by a Map, since they are >> > already overridden...? >> > >> > -----Original Message----- >> > From: Romain Manni-Bucau [mailto:[email protected]] >> > Sent: Freitag, 23. Januar 2015 09:20 >> > To: [email protected] >> > Subject: Re: [DISCUSS] if and how to support Arrays in the config? >> > >> > My idea was Map (compared to properties) has already a nice and java 8 >> > API so we don't need to add another one on top of it (+ it doesnt >> > break java 7 API as well). Less we introduce of concepts better we'll >> > be IMO - easier to use/understand. >> > >> > I agree about not scannable properties...but I doubt it is a real >> > issue in practise, these ones will be very very limited so ignoring >> > them here shouldn't be a big deal. They are by design "broken" >> > sources. Even thought replacing isScannable() by @NotScannable to not >> > make this property a first citizen of the PropertySource API. >> > >> > >> > >> > Romain Manni-Bucau >> > @rmannibucau >> > http://www.tomitribe.com >> > http://rmannibucau.wordpress.com >> > https://github.com/rmannibucau >> > >> > >> > 2015-01-23 8:38 GMT+01:00 Anatole Tresch <[email protected]>: >> >> Reading again I am sure I get your point ;) >> >> What benefits should the convertermanager bring? What api? I dont see >> the >> >> connection to my post. Pleae help! >> >> Anatole Tresch <[email protected]> schrieb am Fr., 23. Jan. 2015 um >> 08:20: >> >> >> >>> Hi Romain >> >>> 1) We already have getProperties() >> >>> 2) non scannable propertysources may be not considered: really bad >> >>> 3) i need the feature only for single keys typically. >> >>> >> >>> So I dont agree ;) >> >>> Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. >> 2015 >> >>> um 07:54: >> >>> >> >>> Hi Anatole, reading your last point I'm tempted to say if we export >> >>>> the config as a map it is doable through converter API so maybe we >> >>>> should give them a bit more space in the API >> >>>> (config.getConverterManager() maybe) >> >>>> >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau >> >>>> http://www.tomitribe.com >> >>>> http://rmannibucau.wordpress.com >> >>>> https://github.com/rmannibucau >> >>>> >> >>>> >> >>>> 2015-01-23 7:49 GMT+01:00 Anatole Tresch <[email protected]>: >> >>>> > Hi Oliver >> >>>> > >> >>>> > The TypeLiteral is also very useful for non muli values. Eg if >> someone >> >>>> > wants to access a parametrized type from a single value. So I think >> >>>> > alternatives not using it are worse. >> >>>> > >> >>>> > I personally clearly prefer the pure String,String design ( >> especially >> >>>> > since i played araound with multiple alternatives in code ). >> Multivalues >> >>>> > can be done with that as well and it adds unnecessary complexity on >> >>>> > propertysource. Also it adds basically a redundant level of config: >> it >> >>>> is >> >>>> > not sufficient to say.I read key 'x.y'. I also must say if I read a >> >>>> single >> >>>> > or a multivalue. So we have logically two redundant config layers. >> For >> >>>> me a >> >>>> > no go. >> >>>> > >> >>>> > Said that for me the outcome is clear: >> >>>> > - we dont need multivalues >> >>>> > - we need typeliterals in addition to what we have. >> >>>> > - we need control about the mechanism that is combining entries of >> >>>> > subsequent proptertsourced, still keeping overrides as default: >> >>>> therefore I >> >>>> > proposed the ValueCollector interface. >> >>>> > Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. >> >>>> 2015 um >> >>>> > 07:28: >> >>>> > >> >>>> >> Yes but we need tons of methods then, one for List, Set, Map, >> >>>> SortedSet, >> >>>> >> SortedMap, MultiMap at least. >> >>>> >> Le 23 janv. 2015 07:16, "Oliver B. Fischer" < >> [email protected]> >> >>>> a >> >>>> >> écrit : >> >>>> >> >> >>>> >> > Hi, >> >>>> >> > >> >>>> >> > I prefer the get(...)/getMultivalue(...) approach. >> >>>> >> > >> >>>> >> > Why? It leads to a cleaner API and expresses the expectation of >> user. >> >>>> >> Even >> >>>> >> > if TypeLiteral is working never liked the code I have to write >> for >> >>>> it. >> >>>> >> > >> >>>> >> > Bye, >> >>>> >> > >> >>>> >> > Oliver >> >>>> >> > >> >>>> >> > Am 21.01.15 um 11:46 schrieb Anatole Tresch: >> >>>> >> > >> >>>> >> >> Which is basically my original proposal. I would say, given >> what we >> >>>> have >> >>>> >> >> discussed so far, it would be interesting what others think. >> >>>> >> >> I personally also think the basic map design is sufficient. So >> lets >> >>>> >> focus >> >>>> >> >> a >> >>>> >> >> bit on that so we can then compare the possible solutions ;) >> >>>> >> >> >> >>>> >> >> Given that I would say we need: >> >>>> >> >> - TypeLiterals for being able to pass exactly what tsrget we >> expect >> >>>> >> >> - the possibility of having more control about how a final >> value is >> >>>> >> >> evaluated based on the values returned by the (multiple) >> property >> >>>> >> sources >> >>>> >> >> >> >>>> >> >> Both festures I think would also be useful for single values. >> So we >> >>>> >> might >> >>>> >> >> define a Functional interface PropertyCollector with: >> >>>> >> >> >> >>>> >> >> string collect(string currecurrentCollected, String newValue); >> >>>> >> >> >> >>>> >> >> Type conversion is still done with the PropertyConverter we >> already >> >>>> have >> >>>> >> >> in >> >>>> >> >> place. >> >>>> >> >> Wdyt? >> >>>> >> >> Romain Manni-Bucau <[email protected]> schrieb am Mi., 21. >> Jan. >> >>>> >> 2015 >> >>>> >> >> um >> >>>> >> >> 11:29: >> >>>> >> >> >> >>>> >> >> Point is if property source is responsible then converters are >> >>>> quite >> >>>> >> >>> useless or design is messy. Was surely a quick win solution >> but I'm >> >>>> >> >>> sure we can do something better. This is possible but change >> the >> >>>> >> >>> design we have of Map<String, String> more or less and >> moreover how >> >>>> >> >>> will you handle maps and other needs? I really think we should >> >>>> stick >> >>>> >> >>> to key=value and let converters handle other formats >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> Romain Manni-Bucau >> >>>> >> >>> @rmannibucau >> >>>> >> >>> http://www.tomitribe.com >> >>>> >> >>> http://rmannibucau.wordpress.com >> >>>> >> >>> https://github.com/rmannibucau >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> 2015-01-21 11:03 GMT+01:00 Tresch, Anatole >> >>>> >> <anatole.tresch@credit-suisse. >> >>>> >> >>> com>: >> >>>> >> >>> (mail from Mark). One of the questions was how to support >> "arrays" >> >>>> at >> >>>> >> >>> all. >> >>>> >> >>> getList(String key); to the PropertySource. Advantage hereby is >> >>>> that >> >>>> >> the >> >>>> >> >>> property source >> >>>> >> >>> based on Strings. Basically this would work as well, though we >> >>>> would >> >>>> >> then >> >>>> >> >>> require >> >>>> >> >>> similar to a JDK 8 collector), because the current "default" >> >>>> strategy >> >>>> >> >>> simply overrides everything >> >>>> >> >>> what you want... >> >>>> >> >>> [email protected]>: >> >>>> >> >>> Given that we have 2 types of config entries returned by a >> >>>> >> PropertySource >> >>>> >> >>> 1) single value properties, 2) multi value (list properties). >> >>>> >> >>> the property source chain into one big list in sequence. The >> >>>> >> >>> MultiValueConverter then can decide what todo with them: >> >>>> >> >>> ordering, given the entries have some format, e.g. key:value, >> also >> >>>> a >> >>>> >> Map >> >>>> >> >>> can be created easily with similar possibilities about handling >> >>>> >> duplicate >> >>>> >> >>> keys etc. >> >>>> >> >>> PropertyConverter, just the for arrays... >> >>>> >> >>> ordering of ALL values as returned by various property sources >> for >> >>>> a >> >>>> >> key. >> >>>> >> >>> the converter then receives this ALL list and can do whatever >> is >> >>>> >> >>> appropriate... >> >>>> >> >>> [email protected]>: >> >>>> >> >>> case of the broader concept, multi-value support. >> >>>> >> >>> converter); >> >>>> >> >>> first class citizen, hereby keeping so we would end up in a >> pretty >> >>>> >> >>> symmetric API: >> >>>> >> >>> converter); >> >>>> >> >>> like: >> >>>> >> >>> single properties), we have a complete symmetric API >> >>>> >> >>> mailto:[email protected]>>: >> >>>> >> >>> functionality? >> >>>> >> >>> annotation >> >>>> >> >>> item >> >>>> >> >>> depending on >> >>>> >> >>> a >> >>>> >> >>> items >> >>>> >> >>> methods for >> >>>> >> >>> require >> >>>> >> >>> available that >> >>>> >> >>> the >> >>>> >> >>> e.g. >> >>>> >> >>> to the >> >>>> >> >>> itemType); >> >>>> >> >>> available that >> >>>> >> >>> e.g. >> >>>> >> >>> to the >> >>>> >> >>> converter, >> >>>> >> >>> e.g. >> >>>> >> >>> to the >> >>>> >> >>> <mailto:[email protected]>>: >> >>>> >> >>> [email protected]<mailto:[email protected]>> >> >>>> >> >>> >> >>>> >> >> >> >>>> >> > -- >> >>>> >> > 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 >> >>>> >> > >> >>>> >> > >> >>>> >> >> >>>> >> >>> >>
