Sure but also implies it reuses some bootstrap spi automatically keeping things consistent. Le 22 janv. 2015 23:02, "Anatole Tresch" <[email protected]> a écrit :
> 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* > >> >
