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