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