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()*;
Of course, the ConfigurationProvider has some kind of SPI, so the effective
implementation of Configuration can be of type A or B or X. But basically
this is it, the details how *Configuration* internally is organized is not
important to the API.
2) a function that maps a key to a Value: *f(key:;String) -> value:String*
-> this can be realized by *Configuration*, hereby being a simply
Supplier<String> functional interface.
3) Mark stated that we also need a Builder, which for me is OK, since it is
another function: *f() -> Builder*
-> Could also be implemented by *ConfigurationProvider*.
-> the builder then can be configured by applying multiple function of
type *f(Builder,x) -> Builder*, where x are to be defined in more
details. Possible items could be
x = key(String), value (String)
x = key(String), Supplier<String>
x = Function<String,String>
x= selector:Predicate<String>,valueSupplier: Function<String,String>
Or something like that.
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);
This mechanism can be used for type support, user based filtering, post
processing, config template generation, conversion into json, yaml and much
more. The important part is to use a well known pattern and reinvent the
wheel, but provide a flexible API here. This pattern could also be added to
the *ConfigurationProvider* but it can be porovided completely independent
of the core API.
5) Another point is that if we minimize *Configuration* IMO the concept of
*PropertySource* makes no sense anymore, because it is duplicating the same
abstraction/functionality already defined in *Configuration: supplying
key/value pairs*. Also taking *filtering* into account, where we have an
unary function *f(Configuration) -> Configuration* (an
UnaryOperator<Configuration> in Java 8), the whole configuration system we
have built can also be mapped using an unidirectional graph of
*Configuration* instances:
interface Configuration extends Function<String,String>{
Configuration getParent();
}
This graph can be built up based on ordinal values. This also solves things
we have currently modelled separately, such as
- filters/resolvers/access control = just another configuration layer
- combination policies = realizable by top level configuration levels,
which can traverse the whole subgrapg for determining a value if needed.
- and much more...
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.
J Anatole
2016-07-20 14:47 GMT+02:00 Mark Struberg <[email protected]>:
> >
> > Am 20.07.2016 um 13:10 schrieb Werner Keil <[email protected]>:
> >
> >
> > That's where I suggested, that the minimum an SPI must provide is the
> > equivalent to PropertySource and maybe PropertySourceProvider. Allowing
> > those extensions to still work with a future design.
>
> Yes, there is finally something we agree on ;)
>
> I probably do care less about existing extensions than you. Any new JSR
> imo doens’t need to bother about existing stuff. I think we agree on this
> part as well, right?
>
> The main reason why I think we need an SPI is because the application
> otherwise has no way to plug in the stuff they need.
>
> That would be like bean-validation without custom
> Constraint+ConstraintValidator. Such a spec would not be worth the energy
> imo.
>
> 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*
