2016-07-19 18:16 GMT+02:00 Anatole Tresch <[email protected]>: > 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); > > This sadly doesn't help since it enters exactly the area we talked about
> Or we allow the client to *traverse* the entries we have using some Visitor > pattern... > > Same there > 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" ;) > > What use case you cant redesign to implement without that issue? it is always possible to list key in another one AFAIK for such needs (generic builder?) and it can even be generated by one source if really needed. > > > 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* >
