I say "we know we cant implement them correctly." That obviously depends on what correctly is defined. We as of now already clearly stated that listing a configuration (or a part of a configuration) may not always work as expected. As an alternative we may also let the configuration provide us some information on configuration parts that are supported to be listed;
boolean isListableKey(String key); Map<String,String> getConfiguration(String listKey); Or we allow the client to *traverse* the entries we have using some Visitor pattern... Not providing any feature will not be understood by users and really would be missed and also would make some extension impossible to implement. So maybe let us think on how we can provide something "less dangerous" ;) 2016-07-19 18:02 GMT+02:00 Romain Manni-Bucau <[email protected]>: > @Anatole: had this case in mind but it brings also a lot of issues (was not > in JCache for one reason ;)) and can often be worked around using a key to > list them (sure you can need to merge entries but in practise a namespace > will be under the responsability of some part of the company so should be > fine). You can also use a custom provider to do that, the provider will see > all sources and thereforce handle a subtype of sources which would be > listable but it would be a specific feature. For case you can't/don't want > list them all - and they are numerous - you would get a wrong result so I > don't see how to make it consistent in the core whatever we do and would > really like to avoid to push features we know we can't implement correctly. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2016-07-19 17:54 GMT+02:00 Anatole Tresch <[email protected]>: > > > Regarding access of single keys only: > > > > - I can live removing the getOrDefault methods. This also enables us > to > > provide a Java 8 compatible extension to configuration, where we can > > provide suppliers for determining values not found from configuration. > > - Same thing applies to converters, where I can pass a > > Function<String,T>. > > > > But there is one important use case, where I ask how you would like to > > implement it: > > > > - I have some code, that defines a namespace, e.g. called *logger* > > - now I want to traverse/evaluate all (direct) child keys of logger, > > e.g. I want to extract the information that logger.mylogger1 and > > logger.mylogger2 has been configured. If I cannot access the > properties, > > I would like to see some query mechanism at least... any propsals? > > > > J A > > > -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
