Anatole/all, So ConfigurationProvider boils down to just a getConfiguration() method now?
On Thu, Jul 21, 2016 at 12:01 PM, Anatole Tresch <[email protected]> wrote: > Hi Mark/all > > that sounds good for me. For me the current state actually is part of some > Kind of Long term trip. We started with some features, we imlpemented use > cases, some People started using it. Now we have some Kind of midlife > break, where we look back and rethink on things done based on the > experience. This is actually not bad, but exactly the Kind of Output, which > is necessary also when talking later with People on the JCP for running a > JSR ;) > As long as it doesn't get too thin for a JSR in the end. You'll remember what happened with 354 after a massive reduction you did with Stephen at JavaOne? Some EC members argued the scope had become too small then. > > Since we agree on many aspects I think we will have good Progress and can > showup reasts quickly. I will, within the next days, put together something > on my *atsticks *Github repository (@Oliver: good news, especially for > people already using Tamaya: most of the things also work OOTB with a new > super small and lean API, since we typically have defined some kind of > "module APIs", which only need adaptions internally. Latest simplifications > already resulted in stronger modularity in the whole system, which is good! > > @Mark: yes, I agree Configuration and the source part are not the same. > Looking at the code I am experimenting with the internal structure (aka > PropertySource) in the current form could end up in an artifact extending > Configuration (from a functionality standpoint), adding up some code, where > the configuration System passes additional Information (e.g. its parent). > With that a PropertySource Looks like some Kind of this: > interface ConfigurationProcessor{ > String get(String key); // Access a key > String getId(); // Get a unique id identifying a processor, > could be a UUID > String getName(); // Get a human readable Name, for Analysis and > admin > int getOrdinal(); // as before > void init(ConfigurationProcessor parent); > // Called on initialization, passing its > (optional) parent > ConfigurationProcessor getParent(); > } > > With that a processor can deliver data, override, or combine as needed. > Ordering of processors into a processor chain etc. is exactly the same > thing we already have (using ordinals). Since we also have access to the > graph structure, we can use the same abstraction for all kind of > functionality: providing config, overriding, collecting (e.g. for > collections), analysis, filtering, access control and much more. > > We may then also add a ConfigurationBuilder, where you can programmatically > put together/Combine your processors and produce your own Configuration on > the fly. > > So given that Overall we would have the following artifacts: > > - ConfigurationProvider > - Configuration > - ConfigurationException > - ConfigurationBuilder > - spi.ConfigurationProcessor > - spi.ConfigurationFactory > > I will come back again, once I am ready, and hopefully also find time to > look into the Details of the mentioned Solutions by Romain in the mean time > to see how this aligns... > > J Anatole > > > Not entirely sure if ConfigurationBuilder and ConfigurationFactory are distinguishable, but once you have that branch or fork somewhere it's easier to see what can be done with it. Cheers, Werner > > 2016-07-21 11:08 GMT+02:00 Mark Struberg <[email protected]>: > > > Hi Anatole! > > > > Thanks for your productive response, anwers inline: > > > > > > > Am 20.07.2016 um 17:00 schrieb Anatole Tresch <[email protected]>: > > > > > > Dont get me wrong: I completely agree we need an SPI, so we can hook > in;) > > > > > > Basically we need: > > > 1) a function for access of Configuration: *f() -> Configuration * > > > -> this can be implemented by > > *ConfigurationProvider.getConfiguration()*; > > > > +1 Some kind of factory. As proposed. > > > > > > > 4) For adding up functionality/implementing interfaces not known by the > > API > > > we can easily add up an independent component and leverage the GoF > > Adapter > > > pattern, realizing a function *f(Configuration) -> x*, x being anything > > > that may make sense. In code this could look like something > > > TypedConfiguration config = AdapterManager > > > .adapt(configuration, TypedConfiguration.class); > > > > Sounds a bit too complicated and I fear that a too ‚generic‘ approach > will > > not be practicable. > > > > > > > 5) Another point is that if we minimize *Configuration* IMO the concept > > of > > > *PropertySource* makes no sense anymore, > > Fine IF we manage to get an easier SPI which is at least as flexible as > > the ConfigSource mechanism. > > Remember we started with 100++ classes for such an interface. > > With the ConfigSource approach this can be made as little as 2 interfaces > > (ConfigSource + ConfigSourceProvider) > > > > > > > because it is duplicating the same > > > abstraction/functionality already defined in *Configuration: supplying > > > key/value pairs*. > > > > No, Configuration is the result of n ‚merged‘ ConfigSources. But they are > > not the same. > > That’s like saying a balance sheet only consists of the final summary > > numbers. > > Of course that’s the most important thing from a managers POV. But how > did > > those numbers got there? > > > > > > > > > > Just to give some ideas. I really believe we dont need much fancy > things, > > > just combine what is already out there. IMO some generic aspects should > > be > > > considered and we are done. > > > > +1, see proposed approach. > > > > Of course it doesn’t need to be 1:1 what I coded. My proposal is just to > > showcase that a possible API could be implemented way more precise (and > > thus smaller) as what Tamaya has right now. > > If you have something better, then show it (plz via patch or on github, > as > > we cannot get rid of any experimental commits from our GIT repos as > > explained before). > > > > LieGrue, > > strub > > > > > > > -- > *Anatole Tresch* > PPMC Member Apache Tamaya > JCP Star Spec Lead > *Switzerland, Europe Zurich, GMT+1* > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > *Twitter: @atsticks, @tamayaconf* >
