Hi Romain, PropertySource#isScannable() should stay IMHO. It is very usefull if you want to support property sources as a DB. Surely no one of us want to see somethink like "SELECT * from properties". So isScannable should stay IMHO.
Oliver Am 22.01.15 um 16:18 schrieb Romain Manni-Bucau:
shouldnt prevent us to go futher but also means we make a lot of noise and no progress... That said here the feedbacks I try to make precise: - java 7 module: -- ConfigurationProvider should be called ConfigurationFactory IMO (see next) - org.apache.tamaya.spi.ServiceContext#getServices should disappear -> no usage at least -- Configuration.current() miss the "config" stage where you can select your impl: Configuration.byDefaultProvider() or Configuration.byProvider(MySuperProvider.class) and then we just call build() (or we can add in between addPropertySource/Converter). Doing it we don't need to cache org.apache.tamaya.spi.ServiceContextManager#serviceContextProviderDelegate which makes it more reliable - org.apache.tamaya.spi.ConfigurationContext#context has no real meaning IMO and shouldn't be public if it is needed (it is not IMO) - org.apache.tamaya.spi.PropertySource#isScannable is not used ATM AFAIK so we should remove it IMO - I'd remove org.apache.tamaya.ConfigOperator and just allow to export a Config as a Map -> then use Map API to actually "map" - ConfigQuery -> same as previous comment -> adapt Configuration with 2 previous comments - finally check it does worth to keep this j8 module (think only drawback removing it would be to loose Configuration.current() - or new equivalent - which is not a big deal IMO. That's what I had in mind more or less Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-22 16:01 GMT+01:00 Tresch, Anatole <[email protected]>:Hi Romain Do we? I am only focused on config related use cases and know about what I am talking: - Exposing a part of the internals as API does not make a storage solution. - Using TypeLiteral for property conversion does not have anything in common with a storage solution. -> So please stay on the topic and keep off things that are not relevant, please. -> Which is providing a configuration solution. I have well defined and well important use cases. If you don’t have them, well... -> I do not care (too much) what other projects do. Often others provide good features, but also some less good ones. To argue not to repeat, what others did IMO is useless. We should take the good things and combine it here, so we get a good solution. And again: if you have something that disturbs you, be explicit. Just claiming or writing down your feelings does not help anybody here. Either you write down your concerns clearly, at the end by code, or your input is not much of use. It is that simple IMO. I am exposing me by writing down and trying to do things as Java API, simply because that is the only way it works to get a common understanding. Sorry for the hard words here. -> So we have a scope discussion for the new release now. IMO the current artifacts within the API are clearly in focus for release 1 (from an API perspective). If you want to remove anything, you should exactly write down, WHAT should be removed and also WHY. -> About Collection support, we may have a vote on it. Or other people here on the mailing list should add their cents ;) -> Gathering feedback is OK. Nevertheless we can mark the release as alpha, so everybody is clear that things may still change. -> And again discussing what should be part of release 1 IMO must not constrain us to discuss on further concepts as long as the threads are clearly separated and not too many. So help us constructively with the discussion instead of throwing woods into our legs all the times. That would be great! Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-22 13:47 GMT+01:00 Tresch, Anatole <[email protected]>:
-- 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
