If the builder api is available (either as module or part of the api) I probably also would use it to build the config instances provided by my registered config provider. Hereby loading exact the resources that are visible within a given context. But basically I have seen that as an implementation detail.
Matches that what you meant? - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile > Am 22.01.2015 um 21:43 schrieb Romain Manni-Bucau <[email protected]>: > > Shouldnt contextual config be built on top of the builder just adding the > spi for servieloader? > Le 22 janv. 2015 21:27, "Anatole Tresch" <[email protected]> a écrit : > >> Hi Romain >> >> so we are on the same page, I hope. I would like to have a service >> providing configuration and have a builder functionality that gives you the >> possibility to create your own Configuration instance by hand. I also dont >> think we need 2c, I just wanted to ask, if we have similar concepts in >> mind. >> As a consequence we would have to add these "builder" stuff into the API. >> This is basically possible, but will required also some SPI defined that >> provide the effective builder implementation. I propose you ensure together >> with Oliver, you get the functionality you would like to see, and we will >> then take up this stream again and discuss integration or extension >> possibility related to the API. Basically the builder functionality can be >> added both as an extension (would then not require an API) or as part of >> the API (I guess you would prefer the ladder)... >> >> OK so far? >> >> >> >> 2015-01-22 21:11 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> >>> not sure why 2c is needed - assuming I got it you want to create a >>> config from the builder and inject it in the system "current()". If >>> you use the builder to create an instance I guess you are fine wiring >>> it to your code yourself so current() would be useless in such a case >>> - could even be general and contextual current() feature could be seen >>> as an extension more generally since it is not bound to runtime API >>> but only bootstrrap (this is also why i prefer this factory pattern >>> than current one in terms of API - impl is close). >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-22 20:32 GMT+01:00 Anatole Tresch <[email protected]>: >>>> 2) I think both approaches are feasible: >>>> 2a) A company (eg Credit Suisse) defines the complete config system and >>>> provides with the infrastructure deployment. Users will never (and this >>> is >>>> good so, mess up with the platform config system). >>>> 2b) You want to setup all manually, so I think the builder support >>> planned >>>> by Oliver is the best. I originally also had some similar approach. >>>> 2c) The question is, if you prefer to register your built >> configurations >>>> somehow, after having created it. Of if you want to have some factory >>>> classes defined by the SPI, which you are then implementing... ? >>>> >>>> >>>> >>>> 2015-01-22 19:59 GMT+01:00 Romain Manni-Bucau <[email protected]>: >>>> >>>>> 1) ok >>>>> >>>>> 2) we spoke about it earlier but I think here a builder would be the >>>>> easiest and cleaner solution. Extensions can work on the builder IMO >>>>> but shouldn't be able to modify at runtime the configuration itself. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-01-22 19:44 GMT+01:00 Anatole Tresch <[email protected]>: >>>>>> Hi Romain¨ >>>>>> >>>>>> so lets focus on the first aspect: >>>>>> >>>>>> 1) I would agree to provide ConfigurationProvider as an accessor >>>>> singleton >>>>>> class in Java 7 and 8 similarly. As a consequence I would agree to >>>>>> remove Configuration.current() >>>>>> in Java 8 and use ConfigurationProvider as the entry point into >> Tamaya >>>>>> config. >>>>>> 2) I would then define a ConfigurationProviderSpi, which implements >>>>> exactly >>>>>> how Configuration instances are managed, depending on the context or >>>>>> whatever is appropriate. This class is loaded from the >> ServiceContext >>>>> once >>>>>> and then hold as a static variable within ConfigurationProvider. >> What >>> is >>>>>> happening inside ConfigurationProvider/ConfigurationProviderSpi is >>>>>> basically completely transparent. In SE it will be true singleton, >> in >>>>>> EE/OSGI environments something different perhaps. >>>>>> >>>>>> -> This should give you a direct OOTB API to decide how >> Configuration >>>>>> instances are managed. >>>>>> >>>>>> 2a) If we would remove ConfigurationContext, we might add the method >>>>>> >>>>>> /** >>>>>> * This method can be used for programmatically adding {@link >>>>>> PropertySource}s. >>>>>> * It is not needed for normal 'usage' by end users, but only >> for >>>>>> Extension Developers! >>>>>> * >>>>>> * @param propertySourcesToAdd the PropertySources to add >>>>>> */ >>>>>> void addPropertySources(PropertySource... propertySourcesToAdd); >>>>>> >>>>>> to the Configuration interface. >>>>>> >>>>>> 2b) The other methods look nevertheless somehow detailed, and when >>>>> writing >>>>>> extensions they may be still very helpful. So basically if we want >> to >>>>>> remove ConfigurationContext completely some of them would end up on >>>>>> Configuration. >>>>>> Best we can do is probably to add a method ConfigurationContext >>>>>> getContext() on Configuration, or on ConfigurationProvider. >>> Disadvantage >>>>> is >>>>>> that PropertyFilter and PropertySource also get API artefacts >>> (basically >>>>>> PropertyConverter already is one, since it can be passed as >> parameter >>> for >>>>>> adhoc conversion), so let's see what Mark thinks on that... >>>>>> >>>>>> WDYT? Would that match at least first couple of aspects you >> mentioned? >>>>>> >>>>>> -Anatole >>>>>> >>>>>> >>>>>> 2015-01-22 17:47 GMT+01:00 Romain Manni-Bucau < >> [email protected] >>>> : >>>>>> >>>>>>> few more comments inline >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-01-22 17:41 GMT+01:00 Tresch, Anatole < >>>>>>> [email protected]>: >>>>>>>> inline as usual >>>>>>>> >>>>>>>> 2015-01-22 16:56 GMT+01:00 Tresch, Anatole < >>>>>>> [email protected]>: >>>>>>>>> Feedback inline: >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Romain Manni-Bucau [mailto:[email protected]] >>>>>>>>> Sent: Donnerstag, 22. Januar 2015 16:18 >>>>>>>>> To: [email protected] >>>>>>>>> Subject: Re: PropertyQuery >>>>>>>>> >>>>>>>>> shouldnt prevent us to go futher but also means we make a lot of >>>>> noise >>>>>>>>> and no progress... >>>>>>>>> -> That depends on the quality of discussion, not on the fact >>> that we >>>>>>> discuss ;). And if you say my posts are noise, well... I take that >>> into >>>>>>> account. Thanks. >>>>>>>> >>>>>>>> we all tend to do it but that's hard to follow where we are and >>>>>>>> finally 1-2 people are doing the product which is bad IMO >>>>>>>> -> I agree. And I also trying to motivate my colluegues to >>> participate >>>>>>> the discussions... >>>>>>>> >>>>>>>>> That said here the feedbacks I try to make precise: >>>>>>>>> -> Nice, thanks! >>>>>>>>> >>>>>>>>> - java 7 module: >>>>>>>>> -- ConfigurationProvider should be called ConfigurationFactory >> IMO >>>>> (see >>>>>>> next) >>>>>>>>> -> NO! NO! NO! We already discussed multiple times that this is >>> not >>>>>>> necessarily a factory. >>>>>>>>> >>>>>>>>> - org.apache.tamaya.spi.ServiceContext#getServices should >>> disappear >>>>> -> >>>>>>>>> no usage at least >>>>>>>>> -> Of course it is used. How do you think the services in core >> are >>>>>>> loaded from? Read the code before you state things that are not >> true >>> or >>>>>>> join our hangouts. >>>>>>>> >>>>>>>> not justified if you prefer. Said otherwise we shouldn't get a >>> single >>>>>>>> ServiceLoader abstraction since both needs are really different. >>>>>>>> -> I do not agree here, but I am not sure I got your point. >>>>>>> ServiceLoader is not powerful enough and users may want to use a >>>>> different >>>>>>> approach. Also for testing you might want to have a more flexible >>>>> solution >>>>>>> as well. >>>>>>> >>>>>>> Point is we are exactly in between 2 states. We should either >> fuilly >>>>>>> control programmatically the config config (the context more or >> less) >>>>>>> with just good default fully overridable or not at all. ATM we >> can't >>>>>>> fully control it but we can modify it a bit which is just a >>> workaround >>>>>>> IMO for several sub config cases. >>>>>>> >>>>>>>> >>>>>>>>> -- 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 >>>>>>>>> -> Obviously you still in case of a factory, which it is not. It >>> is a >>>>>>> service!!! >>>>>>>> >>>>>>>> this is broken in most of environment...just test, check you >>> leaked, >>>>>>>> check you don't have the config you should etc...mainly works in >> SE >>>>>>>> only where this abstraction is useless >>>>>>>> -> Just a claim. Credit Suisse runs plusminus 800 plus instances >>> also >>>>>>> with low latency requirements successfully. Some are running in >>>>> Weblogic, >>>>>>> some in Tomcat, some standalone... >>>>>>>> Also here: your expertise is welcome, but your argument is >>> simply >>>>>>> not true. >>>>>>> >>>>>>> Cause your property sources are not everywhere in the app parts I >>>>>>> guess. You can say I can just switch the "locator" to solve it, it >> is >>>>>>> true but not the default :(. >>>>>>> >>>>>>>>> -> For me it seems you are still stuck in the commons config >>> design >>>>>>> somehow. Oliver BTW is currently trying to build an extension >> module, >>>>> where >>>>>>> you can "build" your configuration in such/similar way. >>>>>>>>> So you can still do your own coding of everything there. We >>> can >>>>>>> then still discuss if we want to have that moved into the core/API >>> part >>>>> at >>>>>>> a later stage. >>>>>>>>> >>>>>>>>> - org.apache.tamaya.spi.ConfigurationContext#context has no real >>>>>>>>> meaning IMO and shouldn't be public if it is needed (it is not >>> IMO) >>>>>>>>> -> tbd. This could be an implementation detail, indeed (or I >>> missed >>>>>>> something). >>>>>>>>> >>>>>>>>> - org.apache.tamaya.spi.PropertySource#isScannable is not used >> ATM >>>>>>>>> AFAIK so we should remove it IMO >>>>>>>>> -> That is not true as well. Non scannable property source are >> not >>>>>>> called for Configuration.getProperties(). >>>>>>>> >>>>>>>> ok - I should have a cache issue in Idea, sorry >>>>>>>> -> fair enough. >>>>>>>> >>>>>>>> >>>>>>>>> - 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 >>>>>>>>> -> Well, JSR 310 as well as JSR 354 use this concept very >>>>> successfully. >>>>>>> I would definitively deny removing it. If you don’t get it talk >> with >>>>>>> Stephen Colebourne. >>>>>>>>> -> In many cases exporting to the full Map is not necessary. >>>>>>>>> -> Creating of views will get implementation dependent. >>>>>>>>> -> Summarizing: no way! IMO useless and inefficient proposal >>> compared >>>>>>> to what we have. >>>>>>>>> >>>>>>>>> - 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. >>>>>>>>> >>>>>>>>> -> Again this is not true again. There are as well the >> additional >>>>>>> accessor using Optional, which are legit additions if someone uses >>> Java >>>>> 8. >>>>>>>> >>>>>>>> yep which is a very poor gain IMO for a lot of complexity: >>>>>>>> -> on our side >>>>>>>> -> on user side (in real life you often have multiple java >> version >>> so >>>>>>>> multiple apis?) >>>>>>>> -> fair enough. your opinion, I have another one! >>>>>>>> >>>>>>>>> -> And to say it again once more: if you don’t want to support >>> Java 8 >>>>>>> as a first citizen, many people here on the list would probably >> leave >>>>> the >>>>>>> project. >>>>>>>> please shout guys if that statement is true >>>>>>>> >>>>>>>> -> yes please! >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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* >>>> >>>> >>>> >>>> -- >>>> *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* >> >> >> >> -- >> *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* >>
