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]>:
> 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]>
> wrote:
>
> > I personally see three types of "collections" useful:
> >
> > 1) List
> > 2) Set
> > 3) Map
> >
> > IMO it is sufficient to let Tamaya support these ones, if users have
> > special requirements, like sorting, reordering, using their
> implementation
> > types, they still can apply them on the result returned, or copy the
> items
> > into their own data structure, or using streams.
> >
> > As mentioned we have basically two options where transformation from the
> > internal "Config Format" into the collection can be implemented:
> >
> > 1) by a mechanism applied during configuration read, e.g. a
> > PropertyConverter as we have of now. This has
> > several drawbacks IMO:
> > - This requires to have a textual representation of all supported
> > collection types.
> > - This will be IMO very error prone.
> > - It implies configuration aspects into the PropertySource, or at
> least
> > how it must be delivered.
> > - Overriding is inflexible, because our system currently only knows
> > full overrides replacing all contents present
> > before. Introducing Override policies as suggested by me earlier
> will
> > make things much more complex, so
> > this is not an option I think..
> > 2) within the property source, looks more promising I think:
> > + the effective format, how config is mapped, can be hidden by the
> > PropertySource implementation
> > + returning a String[] (or List) as part of a property source is not
> > very powerful, but basically enough, since I
> > can convert a ordered list of all items encountered to everything
> > above. For that I propose to define
> > a ListPropertyConverter that converts from String[]/List<String> to
> > whatever is needed: Set, Map, List, Tree or whatever.
> >
> > So summarizing I would propose (discussion base):
> >
> > - I) Add List<String> getListProperty(String key) to PropertySource.
> > - II) Add a ListPropertyConverter interface as follows:
> >
> > public interface ListPropertyConverter<C extends Collection<T>, T> {
> >
> > /**
> > * Convert the given configuration values from it's String
> > representation into the required target type.
> > * Hereby the item values must be of type T. For maps an instance of
> > {@code Map<String,T>}, for
> > * other collections an instance of {@code Collection<T>} must be
> > returned.
> > *
> > * *@param values the configuration values found in order of as
> > delivered by the property source chain.*
> > * * It is possible that similar items are present
> > multiple times. Depedning on the output*
> > * * collection type produced duplicates may be removed,
> > or handled in alternative ways*
> > * * as needed.*
> > * @return the converted value
> > */
> > C convert(List<String> values);
> > }
> >
> >
> > - III) define/add an
> > annotation
> > for converters
> > , e.g. @ConfigConverterSpec(
> > Class<?> targetType
> > , Class
> > <?> itemType default Class.class
> > ),
> > so we
> > can still define PropertyConverter as well as PropertyListConverter
> > as
> > functional interfaces.
> >
> >
> > - IV)
> > ConfigurationContext can be extended similarly
> > , by adding similar converter support for list
> ListPropertyConverters.
> >
> >
> >
> > - V)
> > Configuration
> > would be
> >
> > extended with
> > the following methods:
> >
> > <T> List<T> getList(String key, Class<T> itemType);
> > <T> List<T> getList(String key,
> >
> > PropertyListConverter<List<T>, T> converter);
> >
> > <T> Set<T>
> >
> > getSet(String key, Class<T> itemType);
> >
> >
> > <T> Set<T>
> >
> > getSet(String key,
> >
> >
> > PropertyListConverter<Set<T>, T> converter);
> > <T> Map
> > <String,T>
> >
> > get
> > Map
> > (String key, Class<T> itemType);
> >
> >
> >
> > <T>
> > Map
> > <String,T>
> >
> > get
> > Map
> > (String key,
> >
> >
> > PropertyListConverter<Set<T>, T> converter);
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Thats all of the magic I would need:
> >
> > - I have support for set, lists and maps
> > - I have defined the required target type:
> > - when passing the itemType only it would require a corresponding
> > PropertyAdapter for the type to be present
> > - I can have full control by passing my own PropertyListConverter
> > similar
> > I can do with single values using PropertyConverter
> >
> > BTW: PropertyConverter currently is part of the SPI. But since I can pass
> > it as well as parameter to the API IMO it belongs to the API package...
> >
> > WDYT?
> >
> > Cheers,
> > Anatole
> >
> >
> >
> >
> > 2015-01-18 19:35 GMT+01:00 Werner Keil <[email protected]>:
> >
> > > Well I did not suggest Converters, maybe Romain referred to a different
> > > part of the API (though his example signature mentioned a Converter,
> too)
> > > If you have a method:
> > > Collection<T> getAll() returning a Collection which is in fact backed
> by
> > a
> > > LinkedList or another List, why would you lose its order if you cast it
> > to
> > > a List?
> > >
> > > Trying to cast to say a Set would produce a ClassCastException, one
> could
> > > check this before trying to cast, but if the underlying type is a List
> it
> > > remains a list.
> > >
> > > Werner
> > >
> > > On Sun, Jan 18, 2015 at 7:27 PM, Mark Struberg <[email protected]>
> > wrote:
> > >
> > > > Converters (PropertyAdaptors) do convert the values INSIDE the list.
> > You
> > > > would not be able to distinguish properly.
> > > >
> > > > And casting this to a sorted List makes no sense at all if there are
> > Sets
> > > > used in PropertySources or anywhere in the Configuration system where
> > you
> > > > would loose the natural (configured) original order.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > On Sunday, 18 January 2015, 18:31, Romain Manni-Bucau <
> > > > [email protected]> wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > >Guys we have converters so why do we discuss type?
> > > > >Are converters not able to handle it? If so we have to update them
> > > > removing Class for Type...btw we shouldnt have getTargetType but we
> > > should
> > > > use reflection to get it and keep api clean IMO. See
> AnnotationLiteral
> > or
> > > > TypeLiteral class for samples.
> > > > >Le 18 janv. 2015 18:28, "Werner Keil" <[email protected]> a
> > écrit :
> > > > >
> > > > >Would it be a sacrileg having to cast a Collection to a List or Set
> > > > then?;-)
> > > > >>
> > > > >>Werner
> > > > >>
> > > > >>On Sun, Jan 18, 2015 at 3:15 PM, Mark Struberg <[email protected]>
> > > > wrote:
> > > > >>
> > > > >>> Sometimes sorting MIGHT be important. Consider you configure a
> > > weighted
> > > > >>> list of valid options. Where the one listed first is the most
> > > imported
> > > > one.
> > > > >>>
> > > > >>> LieGrue,
> > > > >>> strub
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> > On Sunday, 18 January 2015, 13:43, Oliver B. Fischer <
> > > > >>> [email protected]> wrote:
> > > > >>> > > Hi,
> > > > >>> >
> > > > >>> > this issue occured already multiple times on this list.
> > > > >>> >
> > > > >>> > I prefer 2b but I would return a set or collection. Sorting is
> > not
> > > > >>> > important as it can be done easily later.
> > > > >>> >
> > > > >>> > But I think the method to access all values must be able to
> > perform
> > > > type
> > > > >>> > conversion as
> > > > >>> >
> > > > >>> > get(String key, PropertyConverter<T> converter)
> > > > >>> >
> > > > >>> > method.
> > > > >>> >
> > > > >>> > My prefered signature looks like this
> > > > >>> >
> > > > >>> > Collection<T> getAll(String key, ProperyConverter<T> converter)
> > > > >>> >
> > > > >>> >
> > > > >>> > WDYT?
> > > > >>> >
> > > > >>> > Bye
> > > > >>> >
> > > > >>> > Oliver
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > Am 17.01.15 um 19:51 schrieb Anatole Tresch:
> > > > >>> >> My views are 1b.
> > > > >>> >>
> > > > >>> >> I am not sure that we can model all aspects with 2b1, so 2a
> > might
> > > > also
> > > > >>> be a
> > > > >>> >> way out, because it would allow us to model the feature as an
> > > > optional
> > > > >>> >> module.
> > > > >>> >>
> > > > >>> >> Here is way:
> > > > >>> >>
> > > > >>> >> Mapping of lists, arrays work fine with 2b1. Sets may work as
> > > well,
> > > > >>> whereas
> > > > >>> >> maps dont really fit.
> > > > >>> >> On top i ask how overriding should work (this question is
> > raising
> > > > for
> > > > >>> both
> > > > >>> >> 2b1 and 2a. With 2a we have a clear rule, though it might not
> > > match
> > > > >>> all use
> > > > >>> >> cases, eg collecting all items configured).
> > > > >>> >>
> > > > >>> >> Given that imo its arguable if a simple additional array
> > accessor
> > > > is
> > > > >>> >> sufficient...
> > > > >>> >>
> > > > >>> >> All these additional aspects are the ones why Looking for
> > > modelling
> > > > >>> >> collections based on simple key/value pairs might be not a
> bad
> > > > >>> solution.
> > > > >>> >> Collections may be mapped to multiple key/value pairs,
> resolved
> > > by
> > > > >>> filters.
> > > > >>> >> We can even add collection accessors of any complexity as
> > > queries,
> > > > >>> being
> > > > >>> >> much more flexible than trying to model / reduce everything
> to
> > a
> > > > simple
> > > > >>> >> array/list...
> > > > >>> >>
> > > > >>> >> Other thaughts...?
> > > > >>> >>
> > > > >>> >> Anatole
> > > > >>> >>
> > > > >>> >> Romain Manni-Bucau <[email protected]> schrieb am Sa.,
> 17.
> > > > Jan.
> > > > >>> > 2015 um
> > > > >>> >> 13:25:
> > > > >>> >>
> > > > >>> >>> 1a and same support as xbean ie you ask and converters do
> what
> > > > they
> > > > >>> can
> > > > >>> > or
> > > > >>> >>> fail
> > > > >>> >>> Le 17 janv. 2015 12:56, "Werner Keil"
> > > > >>> > <[email protected]> a écrit :
> > > > >>> >>>
> > > > >>> >>>> Well, I remember a JSR (not sure which one any more) that
> > > changed
> > > > >>> > such
> > > > >>> >>>> return value or argument from List to Collection to be more
> > > > >>> > versatile.
> > > > >>> >>>> If you have the restriction of unique values then better
> use
> > a
> > > > Set.
> > > > >>> >>> There's
> > > > >>> >>>> also a SortedSet, so all can be sorted, but if you return
> > them
> > > as
> > > > >>> > List
> > > > >>> >>>> only, that excludes Set and vice versa. Returning as
> > Collection
> > > > >>> > allowed
> > > > >>> >>> to
> > > > >>> >>>> treat them specifically to what they really are, if you
> > return
> > > > just
> > > > >>> > one
> > > > >>> >>> of
> > > > >>> >>>> the subtypes, you restrict users from the other.
> > > > >>> >>>>
> > > > >>> >>>> Werner
> > > > >>> >>>>
> > > > >>> >>>> On Sat, Jan 17, 2015 at 12:47 PM, Mark Struberg
> > > > >>> > <[email protected]>
> > > > >>> >>> wrote:
> > > > >>> >>>>> The underlying question is whether sorting is important or
> > > not.
> > > > >>> >>>>> I think it is, and thus I'd prefer a List.
> > > > >>> >>>>>
> > > > >>> >>>>> LieGrue,
> > > > >>> >>>>> strub
> > > > >>> >>>>>
> > > > >>> >>>>>
> > > > >>> >>>>>
> > > > >>> >>>>>
> > > > >>> >>>>>> On Saturday, 17 January 2015, 12:35, Werner Keil <
> > > > >>> >>>> [email protected]>
> > > > >>> >>>>> wrote:
> > > > >>> >>>>>>> About 3)
> > > > >>> >>>>>> I would return a Collection which is the most common
> > > > >>> > foundation to
> > > > >>> >>> both
> > > > >>> >>>>>> List and Set. Unless there was a special requirement
> > > > >>> > somewhere like
> > > > >>> >>> "no
> > > > >>> >>>>>> duplicates" that's where a Set would be better.
> > > > >>> >>>>>>
> > > > >>> >>>>>> And if Tamaya supports collections I am not biased
> towards
> > > > >>> > arrays,
> > > > >>> >>>> since
> > > > >>> >>>>> in
> > > > >>> >>>>>> most cases you can use both in a very similar way now,
> e.g.
> > > > >>> > loop over
> > > > >>> >>>>> them.
> > > > >>> >>>>>> Werner
> > > > >>> >>>>>>
> > > > >>> >>>>>>
> > > > >>> >>>>>> On Sat, Jan 17, 2015 at 9:51 AM, Mark Struberg
> > > > >>> > <[email protected]>
> > > > >>> >>>>> wrote:
> > > > >>> >>>>>>> Hi!
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> 1.) Do we like to support arrays at all?
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> 1.a.) yes, in any case. They are really needed.
> > > > >>> >>>>>>> 1.b.) yes, if we can do easily. They are nice to
> > > > >>> > have. But only if
> > > > >>> >>>>> easily
> > > > >>> >>>>>>> doable.
> > > > >>> >>>>>>> 1.c.) Nope, we don't need it. A user can easily
> > > > >>> > add this himself by
> > > > >>> >>>>>>> String.split, etc
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> I'd prefer 1.b.)
> > > > >>> >>>>>>>
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> How to support arrays. Do we like to
> > > > >>> >>>>>>> 2.a.) map them to String representation or do we like
> > > > >>> > to
> > > > >>> >>>>>>> 2.b.) have a String[] getArray(String key) in our
> > > > >>> > PropertySource.
> > > > >>> >>> In
> > > > >>> >>>>> that
> > > > >>> >>>>>>> case
> > > > >>> >>>>>>> 2.b.1.) do we like to have String[] getArray(key) in
> > > > >>> > addition to
> > > > >>> >>>> String
> > > > >>> >>>>>>> get(key) or
> > > > >>> >>>>>>> 2.b.2.) only have String[] get(key) and only return a
> > > > >>> > single value
> > > > >>> >>> in
> > > > >>> >>>>> it
> > > > >>> >>>>>>> for a get(key) call?
> > > > >>> >>>>>>>
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> I personally like 2.b.1 the most, but not 100% sure
> > > > >>> > yet.
> > > > >>> >>>>>>>
> > > > >>> >>>>>>>
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> 3.) What type should we return at all?
> > > > >>> >>>>>>> 3.a.) Should we return []
> > > > >>> >>>>>>> 3.b.) or List?
> > > > >>> >>>>>>> 3.c.) Or even a Set?
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> I'd prefer 3.a or 3.b as the order sometimes is
> > > > >>> > important. We could
> > > > >>> >>>>>> also
> > > > >>> >>>>>>> think about enhancing the Filter to allow re-sorting
> > > > >>> > those values
> > > > >>> >>> if
> > > > >>> >>>>>> needed.
> > > > >>> >>>>>>> We also have to think about at which point we apply
> > > > >>> > the
> > > > >>> >>>>> PropertyAdapter.
> > > > >>> >>>>>>> I'd also love to have something like getArray (or
> > > > >>> > getList if we
> > > > >>> >>>> decide
> > > > >>> >>>>>> on
> > > > >>> >>>>>>> that)
> > > > >>> >>>>>>> <T> T[] getArray(String key), Class<T>
> > > > >>> > targetType);
> > > > >>> >>>>>>> Where each value in the String[] gets converted with
> > > > >>> > the
> > > > >>> >>>>> PropertyAdapters
> > > > >>> >>>>>>> already inside Tamaya.
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> Any thoughts?
> > > > >>> >>>>>>>
> > > > >>> >>>>>>>
> > > > >>> >>>>>>> LieGrue,
> > > > >>> >>>>>>> strub
> > > > >>> >>>>>>>
> > > > >>> >
> > > > >>> > --
> > > > >>> > 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
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
