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