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* >
