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 <[email protected]>: > 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 >>>> >> > >>>> >> > >>>> >> >>>> >>>
