yep... 2016-07-21 14:08 GMT+02:00 Werner Keil <[email protected]>:
> 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* > > > -- *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*
