Hi, On Thu, Jul 21, 2016 at 11:08 AM, Mark Struberg <[email protected]> wrote:
> Hi Anatole! > > Thanks for your productive response, anwers inline: > > Are we collecting tasks or other items in JIRA, ideally before a hangout? > > > 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) > > +1 ConfigSource sounds a bit closer to what Tamaya is about. The source can be Properties, DB or whatever, so PropertySource while it works very well sounded a bit like it was only for Properties ;-) > > > 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). > > Sorry but I see absolutely no reason why to hide things or purge them later. Maybe not every Apache or other "Open Source" project even if they have the word "Open" in it, but the JCP does require transparency for quite a while now. There should be no "secret attic" where things are hidden or experimented with. Using Git there are probably easier ways to deal with it, but e.g. Tomcat still under SVN has this http://svn.apache.org/repos/asf/tomcat/sandbox/ Same in DeviceMap except they called it https://svn.apache.org/viewvc/devicemap/whiteboard/ (similar to another project Bertrand set up) Cheers, Werner > LieGrue, > strub > >
