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 > >>>> >> > > >>>> >> > > >>>> >> > >>>> > >>> >
