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 > >>well why I want to step back is just cause we slowly leave config >>field and we are implementing a storage solution. > > 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. > >>There are already >>numerous projects doing it at apache - even if they can sometimes >>mandate some infra - so we should stick to the first goal of tamaya. > > -> 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. > >> I also not fully agree with the basis - in particular the SPI to be >> clear - we have ATM. >> >>To sumamrize a first release with: >>1) SPI ("provider" + property source) >>2) basic merge/conflict policy >>3) String read API >>4) basic convertion support >> >>Is far enough IMO. >> >>Once all of it is clear I'd like we do a release to gather feedback >>then continue building on top of it - we are ATM in the tunnel ;). > > -> 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]>: >> Hi Romain/all >> >> I think we have quite a common agreement on the basic functions designed so >> far and I do not want to >> reinvent or change any of the basic mechanism. I simply come up with a >> simple request to use the algorithm pattern >> for a small subset of a functionality (how the final property value is >> evaluated). The usage of TypeLiteral was even your >> own proposal AFAIK, when we discussed PropertyConverters ;) ). >> >> Our current configuration model in general IMO is a very good start. It is >> already so flexible that I can implement 60-70% of use cases >> I have currently in use within Credit Suisse (this is somehow my >> "benchmark", which from my discussions I had during the last years covers a >> majority of use cases when dealing with distributed and modular systems). >> >> I am sure you remember, we had a discussion on another mail thread >> yesterday about Collection support. My proposal >> basically is the outcome of having played around to extend our API to >> support collections based only on Map<String,String> >> only as internal PropertySource representation thus avoiding the String[] >> getListProperty(String) methods. >> >> So for getting type information and define the content type of collections >> we need TypeLiterals, which similarly is useful perhaps for other non >> collection >> cases. Since collection entries can be defined in different property >> sources, a final list may want to contain all the properties found, instead >> of overriding, >> so values of different property sources are to be combined. AFAIK you >> already agreed on that UC. Hardcoding yet another strategy IMO makes >> no sense, so I would recommend use the default for all common aspects (that >> is what we already have in place) and add support for adapting the default >> where it is not appropriate. Thinking on this IMO both aspects (TypeLiterals >> and the collector) are the same for evaluating single property values as >> well, >> so regarding that it makes no sense to model collections differently, but >> extend/flexibilize the way how we can access properties in general. >> >> I tried to combine both aspects in one class, which I called PropertyQuery. >> Perhaps also the name PropertyQuery is confusing. Alternates would be >> PropertyRequest, PropertyAccess,... or whatever you like, I am completely >> open here ;) >> >> We can postpone that discussion, but just stopping this discussion now will >> not solve anything. Also we already invested a lot of discussing collection >> support, why stop here. >> We have enough time I think. We have important use cases to solve that may >> affect the Configuration interface as a whole. Adding them later may be a >> bad idea, so we >> should sort out these things now IMO. >> >> So I am curious to see your concrete (improvement) proposals ;), so we can >> continue to see, if we end up in a common view. If so, others on the mailing >> list also have a >> chance to join us again, I think. >> >> Anatole >> >> >> -----Original Message----- >> From: Romain Manni-Bucau [mailto:[email protected]] >> Sent: Donnerstag, 22. Januar 2015 09:45 >> To: [email protected] >> Subject: Re: PropertyQuery >> >> not exactly, it is different to expose MapReduce in API and to >> implement it behind another concept, ATM it is an implementation >> detail. >> >> Why I worry a bit about Query stuff is we start to leave configuration >> layer to enter backend one, not sure it does worth it *to start* - I >> understand your feature even if I never needed it but I'd really like >> we ensure our basis are solid enough before adding features on top of >> them. >> >> Said otherwise I think we should now focus on trying to make a 0.1 - >> we can add alpha to make obvious we are not done - and stop adding >> anything before being fully agree on all we have. >> >> Does it make sense? >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-22 9:39 GMT+01:00 Anatole Tresch <[email protected]>: >>> Hi Romain >>> >>> About lamba friendly I can still have a Builder that creates a query. Works >>> perfectly. >>> The default use cases would remain as is. Queries would just add about 3 >>> methods to Configuration. We get as well all the flexibility we would need >>> for collection support as well ;) >>> >>> Mapreduce? Well what else is evaluating a chain of propsources by >>> overridding? Its already there, but hardcoded the same, which is obviously >>> not flexible enough! >>> >>> - >>> Anatole Tresch >>> Glärnischweg 10 >>> 8620 Wetzikon >>> Tel +41 (43) 317 05 30 >>> - >>> Send from Mobile >>> >>>> Am 22.01.2015 um 09:11 schrieb Romain Manni-Bucau <[email protected]>: >>>> >>>> isnt it too complicated for most common use cases (+ not that lambda >>>> friendly cause of the 4 parameters which dont help writing readable >>>> code IMO). >>>> >>>> Functionally it works but it makes default cases "hard" and actually >>>> you just want to implement the MapReduce pattern so maybe we should >>>> call it this way if we go this way. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-01-22 8:44 GMT+01:00 Anatole Tresch <[email protected]>: >>>>> Dear all >>>>> >>>>> *let's think about additional use cases:* >>>>> 1) as mentioned in my last mail about collection types,* overriding may >>>>> not >>>>> always be the right resolution policy *for accessing a configured value >>>>> (e.g. for collecting all configured values in a final set/list). >>>>> 2) sometimes I want to define my own PropertyConverters (already >>>>> implemented) >>>>> 3) sometimes I even would like to evaluate multiple keys taking the result >>>>> of the first property key that returns a config property (nice >>>>> convenience) >>>>> >>>>> When we will add all this kind of aspect into Configuration, we will end >>>>> up >>>>> in a messy interface, e.g. for >>>>> String get(String); >>>>> <T> T get(String, Class<T>); >>>>> <T> T get(String, Class<T>, PropertyConverter); >>>>> >>>>> String get(String, ValueCollector); >>>>> <T> T get(String, Class<T>, ValueCollector); >>>>> <T> T get(String, Class<T>, PropertyConverter, ValueCollector); >>>>> ... >>>>> >>>>> Obviously that does not make sense. >>>>> >>>>> Instead of I would propose, we would define a PropertyQuery, which >>>>> basically is >>>>> >>>>> - is the same as a TypeLiteral<T> solving the type aspects >>>>> - has a list of *keys* to be evaluated, at least one >>>>> - optionally has a ValueCollector >>>>> - optionally has a list of PropertyConverter >>>>> >>>>> With that our interface gets much leaner, but still flexible enough to >>>>> accommodate the use cases above: >>>>> >>>>> String get(String); >>>>> <T> T get(String, Class<T>); >>>>> <T> T get(String, Class<T>, PropertyConverter); // may be ommitted as >>>>> well ? >>>>> <T> get(PropertyQuery<T> query); >>>>> ... >>>>> >>>>> This solves all use cases above and gives us an easy way to add additional >>>>> feature, if needed (I dont see any, but who knows). Hereby ValueCollector >>>>> would be defined as follows: >>>>> >>>>> @FunctionalInterface >>>>> public interface ValueCollector { >>>>> >>>>> /** >>>>> * Method that is called for each value returned by a PropertySource >>>>> for the given key. >>>>> * @param currentValue the current value, including null. >>>>> * The collector should either combine the existing >>>>> value with value from {@code currentValue} >>>>> * or replace the value in {@code currentValue} >>>>> with {@code valueRead}, hereby returning the >>>>> * result to be used as new {@code currentValue}. >>>>> * @param key The current key to be evaluated. >>>>> * @param newValue the new value read from the current {@code >>>>> propertySource}, not null. >>>>> * @param propertySource The PropertySource that returned the current >>>>> value (either as the result of a direct >>>>> * access of as a property Map containing the >>>>> given key. The PropertySource given >>>>> * may be evaluated for additional meta-data, how >>>>> the given values are to be combined. >>>>> * @return the value to be used for future evaluation. >>>>> */ >>>>> String collect(String key, String newValue, PropertySource >>>>> propertySource, >>>>> String currentValue); >>>>> >>>>> /** >>>>> * Default overriding collector. >>>>> */ >>>>> public final ValueCollector DEFAULT_OVERRIDING_COLLECTOR = (k, nv, ps, >>>>> cv) -> nv; >>>>> } >>>>> >>>>> Feedback? >>>>> >>>>> Cheers, >>>>> Anatole
