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>: > > Not sure if I get your point. Originally we discussed several variants > (mail from Mark). One of the questions was how to support "arrays" at all. > > It was the idea of Mark, to add an additional method String[] > getList(String key); to the PropertySource. Advantage hereby is that the > property source > > internally has control about the array formatting. > > Of course, we also could define some kind of syntax and do basically all > based on Strings. Basically this would work as well, though we would then > require > > to think on passing alternate combination strategies (or something > similar to a JDK 8 collector), because the current "default" strategy > simply overrides everything > > with the same key, which in case of collection entries is not always > what you want... > > > > -----Original Message----- > > From: Romain Manni-Bucau [mailto:[email protected]] > > Sent: Mittwoch, 21. Januar 2015 10:23 > > To: [email protected] > > Subject: Re: [DISCUSS] if and how to support Arrays in the config? > > > > hmm, this look overcomplicated to me since most of the time csv > > support in the Map will be enough (means any property source can > > contribute array friendly values) > > > > no? > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2015-01-21 10:17 GMT+01:00 Tresch, Anatole < > [email protected]>: > >> Hi Romain > >> > >> originally we discussed adding array support to the PropertySource. > Given that we have 2 types of config entries returned by a PropertySource > 1) single value properties, 2) multi value (list properties). > >> > >> Basically we can collect all the arrays returned by property sources in > the property source chain into one big list in sequence. The > MultiValueConverter then can decide what todo with them: > >> creating a set, but keep the ordering, creating a set, loose the > 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. > >> This is basically exact the same we have with a normal > PropertyConverter, just the for arrays... > >> > >> So ordinal will sort the PropertySources and with that will define the > 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... > >> > >> Anatole > >> > >> > >> -----Original Message----- > >> From: Romain Manni-Bucau [mailto:[email protected]] > >> Sent: Mittwoch, 21. Januar 2015 09:30 > >> To: [email protected] > >> Subject: Re: [DISCUSS] if and how to support Arrays in the config? > >> > >> hmm I maybe didnt get it right > >> > >> multivalue means multiple time the same key? if yes ordinal will merge > >> them. If not and that's a CSV (or anything equivalent) value for a key > >> then TypeLiteral is enough, no need of any multi stuff. We just need > >> to provide few default literals, no? > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-21 9:21 GMT+01:00 Tresch, Anatole < > [email protected]>: > >>> Hi all > >>> > >>> > >>> > >>> I would even say, generally speaking, collections are only one use > case of the broader concept, multi-value support. > >>> > >>> With normal value we do: > >>> > >>> > >>> > >>> String get(String key); > >>> > >>> <T> T get(String key, Class<T> type); > >>> > >>> <T> T get(String key, PropertyConverter<T> converter); > >>> > >>> > >>> > >>> Basically for multivalues we could do: > >>> > >>> > >>> > >>> List<String> getMultiValue(String key); > >>> > >>> <T> T getMultiValue(String key, TypeLiteral type); > >>> > >>> <T> T getMultiValue(String key, PropertyMultiValueConverter<T> > converter); > >>> > >>> > >>> > >>> Looking at that we perhaps want to add TypeLiteral support more as a > first class citizen, hereby keeping so we would end up in a pretty > symmetric API: > >>> > >>> > >>> > >>> String get(String key); > >>> > >>> <T> T get(String key, Class<T> type); > >>> > >>> <T> T get(String key, TypeLiteral<T> type); > >>> > >>> <T> T get(String key, PropertyConverter<T> converter); > >>> > >>> > >>> > >>> Basically for multivalues we could do: > >>> > >>> > >>> > >>> List<String> getMultiValue(String key); > >>> > >>> <T> T getMultiValue(String key, TypeLiteral<T> type); > >>> > >>> <T> T getMultiValue(String key, Class<T> type); > >>> > >>> <T> T getMultiValue(String key, PropertyMultiValueConverter<T> > converter); > >>> > >>> > >>> > >>> > >>> > >>> For completeness sake the PropertyMultiValueConverter<T> would look > like: > >>> > >>> > >>> > >>> public interface ListPropertyConverter<T> { > >>> > >>> T convert(List<String> values) ; > >>> > >>> } > >>> > >>> > >>> > >>> IMO this would be a good compromise: we have all flexibility (also for > single properties), we have a complete symmetric API > >>> > >>> and still its quite small… > >>> > >>> The only disadvantage is we have to add some TypeLiteral type… > >>> > >>> > >>> > >>> Anatole > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Romain Manni-Bucau [mailto:[email protected]] > >>> Sent: Mittwoch, 21. Januar 2015 08:37 > >>> To: [email protected] > >>> Subject: Re: [DISCUSS] if and how to support Arrays in the config? > >>> > >>> > >>> > >>> we should support it IMO (=converter in java 8 module maybe) but it > >>> > >>> can't be the first citizen since most of the time for a config you > >>> > >>> dont' want just streams and need List or Set features (Collection and > >>> > >>> Iterable are not enough). Since we can get them for free and stream > >>> > >>> are just one method call (java 8 loves it :p) then not sure it is an > >>> > >>> issue > >>> > >>> > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> > >>> @rmannibucau > >>> > >>> http://www.tomitribe.com > >>> > >>> http://rmannibucau.wordpress.com > >>> > >>> https://github.com/rmannibucau > >>> > >>> > >>> > >>> > >>> > >>> 2015-01-21 8:22 GMT+01:00 Oliver B. Fischer <[email protected]< > mailto:[email protected]>>: > >>> > >>>> Why can't we use the stream collectors of Java 8 or similar > functionality? > >>> > >>>> > >>> > >>>> Oliver > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> Am 20.01.15 um 00:47 schrieb Anatole Tresch: > >>> > >>>>> > >>> > >>>>> Of course, nevertheless we could do something like that: > >>> > >>>>> > >>> > >>>>> public interface ListPropertyConverter<T> { > >>> > >>>>> Class<T> getTargetType(); // or better use @ConverterSpec > annotation > >>> > >>>>> T convert(List<String> values, List<PropertyConverter<I>> > >>> > >>>>> propertyConverter); > >>> > >>>>> } > >>> > >>>>> > >>> > >>>>> This is the same principle as applied with single valued > >>> > >>>>> PropertyConverters. > >>> > >>>>> The only difference is that, we pass to the ListPropertyConverter > >>> > >>>>> additionally > >>> > >>>>> the item converters to be used (alternatively we could also pass the > item > >>> > >>>>> type, but in that case different parsing behaviour may result > depending on > >>> > >>>>> the List converter implementation). > >>> > >>>>> > >>> > >>>>> So the PropertyListConverter implementation is responsible for > >>> > >>>>> creating the *list > >>> > >>>>> property type*, whatever it is. It could be a List, an Array, a Map, > a > >>> > >>>>> tree, or something completely different, whereas the parsing of the > items > >>> > >>>>> contained in the list is done by the PropertyConverters in place. > >>> > >>>>> > >>> > >>>>> On API side (Configuration) we simply could add two additional > methods for > >>> > >>>>> Java 7: > >>> > >>>>> > >>> > >>>>> /** > >>> > >>>>> * Get the list property key as type T. This will implicitly > require > >>> > >>>>> a > >>> > >>>>> corresponding {@link > >>> > >>>>> * org.apache.tamaya.spi.ListPropertyConverter} to be > available that > >>> > >>>>> is > >>> > >>>>> capable current providing type T > >>> > >>>>> * and corresponding {@link PropertyConverter} for converting > the > >>> > >>>>> single items to their required > >>> > >>>>> * target type {@code itemType}. > >>> > >>>>> * > >>> > >>>>> * @param key the property's absolute, or relative path, > e.g. > >>> > >>>>> @code > >>> > >>>>> * a/b/c/d.myProperty}. > >>> > >>>>> * @param type The target type required, not null. > >>> > >>>>> * @param itemType The item type to be passed to the {@link > >>> > >>>>> org.apache.tamaya.ListPropertyConverter}. > >>> > >>>>> * @return the property value, never null.. > >>> > >>>>> * @throws ConfigException if the keys could not be converted > to the > >>> > >>>>> required target type. > >>> > >>>>> */ > >>> > >>>>> <T> T getListProperty(String key, Class<T> type, Class<?> > itemType); > >>> > >>>>> > >>> > >>>>> /** > >>> > >>>>> * Get the list property key as type T. This given {@link > >>> > >>>>> * org.apache.tamaya.spi.ListPropertyConverter} to be > available that > >>> > >>>>> is > >>> > >>>>> capable current providing type T > >>> > >>>>> * is used, hereby creating items of type {@code itemType}. > >>> > >>>>> * > >>> > >>>>> * @param key the property's absolute, or relative path, > e.g. > >>> > >>>>> @code > >>> > >>>>> * a/b/c/d.myProperty}. > >>> > >>>>> * @param converter the {@link > >>> > >>>>> org.apache.tamaya.ListPropertyConverter} > >>> > >>>>> used, not null. > >>> > >>>>> * @param itemType The item type to be passed to the {@link > >>> > >>>>> org.apache.tamaya.ListPropertyConverter}. > >>> > >>>>> * @return the property value, never null.. > >>> > >>>>> * @throws ConfigException if the keys could not be converted > to the > >>> > >>>>> required target type. > >>> > >>>>> */ > >>> > >>>>> <T> T getListProperty(String key, ListPropertyConverter<T> > converter, > >>> > >>>>> Class<?> itemType); > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> ...and one method for Java 8, enabling functional support: > >>> > >>>>> > >>> > >>>>> /** > >>> > >>>>> * Get the list property key as type T, hereby using the given > >>> > >>>>> function > >>> > >>>>> for conversion. > >>> > >>>>> * > >>> > >>>>> * @param key the property's absolute, or relative path, > e.g. > >>> > >>>>> @code > >>> > >>>>> * a/b/c/d.myProperty}. > >>> > >>>>> * @param converter the conversion function to be used. > >>> > >>>>> * @return the property value, never null.. > >>> > >>>>> * @throws ConfigException if the keys could not be converted > to the > >>> > >>>>> required target type. > >>> > >>>>> */ > >>> > >>>>> <T> T getListProperty(String key, Function<List<String>, T> > >>> > >>>>> converter); > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> 2015-01-18 22:23 GMT+01:00 Werner Keil <[email protected] > <mailto:[email protected]>>: > >>> > >>>>> > >>> > >>>>>> Map is another interface not related to Collection as such. > >>> > >>>>>> If we must return each of them separately, it may have to be on a > >>> > >>>>>> case-by-case basis;-) > >>> > >>>>>> > >>> > >>>>>> Werner > >>> > >>>>>> > >>> > >>>>>> On Sun, Jan 18, 2015 at 10:11 PM, Anatole Tresch < > [email protected]<mailto:[email protected]>> > >>> > >>>>>> wrote: > >>> > >>>>>> > >>> > >>>>>> implementation > >>> > >>>>>> items > >>> > >>>>>> least > >>> > >>>>>> will > >>> > >>>>>> ListPropertyConverters. > >>> > >>>>>> too) > >>> > >>>>>> by > >>> > >>>>>> could > >>> > >>>>>> it > >>> > >>>>>> AnnotationLiteral > >>> > >>>>>> bad > >>> > >>>>>> resolved > >>> > >>>>>> to > >>> > >>>>>> 17. > >>> > >>>>>> what > >>> > >>>>>> use > >>> > >>>>>> towards > >>> > >>>>>> e.g. > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> > >>> > >>>> > >>> > >>>> -- > >>> > >>>> N Oliver B. Fischer > >>> > >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >>> > >>>> P +49 30 44793251 > >>> > >>>> M +49 178 7903538 > >>> > >>>> E [email protected]<mailto:[email protected]> > >>> > >>>> S oliver.b.fischer > >>> > >>>> J [email protected]<mailto:[email protected]> > >>> > >>>> X http://xing.to/obf > >>> > >>>> >
