You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <at...@gmail.com> on 2017/02/06 19:02:05 UTC
Removing ordinals/getOrdinal()
Hi all
In the microprofile.io group we are currently discussing and defining a
minimalistic configuration API. Most of the things look quite compatible
with out approach. Nevertheless I was also sharing my thaughts regarding
the "ordinal concept" on my blog here,:
https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-
sources/
<https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-sources/>
*Quick Summary:*
*I think ordinals have too many downsides and I consider them only as one
implementation of a more wider concept: A mapping function of ConfigSources
to a Configuration. *Even the fact that I have a well defined
unidirectional tree of sources is a design decision. Even, when I define
that a configuration value is determined by walking along a well ordered
list of config sources, the ordering is not necessaRILY AUTOMATICALLY
APPLIED:
1) When *using a Builder* for defining my Configuration, I *explicitly
define my config source ordering.* NO AUTOMATISM AT ALL.
*DONE*: In Tamaya this can be achieved by implementing the
*ConfigProviderSpi*.
2) When *collecting config sources* as they are registered, *I can evaluate
some ordinal for each of them to determine the order. This does not require
the ordinal to be defined on the ConfigSource API, *I can access it as an
ordinary config value from the Config Source.
3) When I have a use case, where I want to have an *additional criteria in
place, with only ordinals I can get into an big mess.* Imagine I want to
have my configuration sources not only ordered by their ordinal, but also
by some other criteria, such as a grouing. E.g. there are use cases, where
file based configuration must be handled differently than classpath based
conifig, but there are also different priorities (default and explicit
values) within each configuration group. In this case ordinals are not
sufficient anymore and I end up with hyper complex logic to make these
things working by wrapping everything, so I can define all ordinals as
needed at the end of my ConfigSource collection phase. Nobody wants to do
that.
All these aspects can be solved by
- defining a *Builder*, which *by default does not sort the sources added
(DONE)*
- let the builder *perform sorting on its config sources by passing the
Comparator to be applied (DONE).* This could be the one using some ordinal
values calculated, or a more complex logic).
- the *builder supports adding property sources explicitly, or loading the
automatically registered at the end of the current chain (also not
performing any sorting implicitly)*. This also allows to define parts of
the configuration setup programmtically, but still using the default
loading logic for registered config sources. (DONE)
*See Tamaya's ConfigurationContextBuilder as an example for this*. BTW the
*metamodel* module in Tamaya's sandbox basically is nothing more than an *XML
based configuration that is backed by this kind of Builder apporach*. It
allows as well to add preregistered config sources, but also allows to
explicitly hard code property sources being added.
All items marked with *RED* are already implemented in the current Tamaya
head. So I was looking for a way to implement (2) in our API. Basically my
approach proposed would be:
- Remove the *getOrdinal()* method from the *PropertySource*.
- Extend the existing *PropertySourceComparator* (this is the one
responsible for ordering the automatically loaded property sources on
startup by default) to implement the following logic:
- Check if the *PropertySource* provides an *int* convertible value
for the key *"tamaya.ordinal"*.
- Check via reflection for a *getOrdinal() *method.
- Check for a *@Priority* annotation's value.
- Use 0 as *default*.
Overall the code change needed in all implementations would be to remove
the @Override annotation on any existing getOrdinal() method.
Please discuss the idea: I am well aware that this equals to an API change.
Is it worth? Or not?
Do you have better implementation alternatives/ideas?
Thanks, J Anatole
--
*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*
Re: Removing ordinals/getOrdinal()
Posted by Werner Keil <we...@gmail.com>.
Guess there's no hurry. I have more dentist (somehow they always have time
on Mon after 6pm;-O) every 2 weeks, but next week should work, so maybe we
can discuss it in the hangout, too.
On Tue, Feb 7, 2017 at 1:20 PM, Oliver B. Fischer <o....@swe-blog.net>
wrote:
> I have to think about it first...
>
>
> Am 06.02.17 um 20:02 schrieb Anatole Tresch:
>
> Hi all
>>
>> In the microprofile.io group we are currently discussing and defining a
>> minimalistic configuration API. Most of the things look quite compatible
>> with out approach. Nevertheless I was also sharing my thaughts regarding
>> the "ordinal concept" on my blog here,:
>> https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-
>> sources/
>> <https://maketechsimple.wordpress.com/2017/01/04/composing-
>> configuration-sources/>
>>
>> *Quick Summary:*
>>
>> *I think ordinals have too many downsides and I consider them only as one
>> implementation of a more wider concept: A mapping function of
>> ConfigSources
>> to a Configuration. *Even the fact that I have a well defined
>> unidirectional tree of sources is a design decision. Even, when I define
>> that a configuration value is determined by walking along a well ordered
>> list of config sources, the ordering is not necessaRILY AUTOMATICALLY
>> APPLIED:
>> 1) When *using a Builder* for defining my Configuration, I *explicitly
>> define my config source ordering.* NO AUTOMATISM AT ALL.
>> *DONE*: In Tamaya this can be achieved by implementing the
>> *ConfigProviderSpi*.
>> 2) When *collecting config sources* as they are registered, *I can
>> evaluate
>> some ordinal for each of them to determine the order. This does not
>> require
>> the ordinal to be defined on the ConfigSource API, *I can access it as an
>> ordinary config value from the Config Source.
>> 3) When I have a use case, where I want to have an *additional criteria in
>> place, with only ordinals I can get into an big mess.* Imagine I want to
>> have my configuration sources not only ordered by their ordinal, but also
>> by some other criteria, such as a grouing. E.g. there are use cases, where
>> file based configuration must be handled differently than classpath based
>> conifig, but there are also different priorities (default and explicit
>> values) within each configuration group. In this case ordinals are not
>> sufficient anymore and I end up with hyper complex logic to make these
>> things working by wrapping everything, so I can define all ordinals as
>> needed at the end of my ConfigSource collection phase. Nobody wants to do
>> that.
>>
>> All these aspects can be solved by
>> - defining a *Builder*, which *by default does not sort the sources added
>> (DONE)*
>> - let the builder *perform sorting on its config sources by passing the
>> Comparator to be applied (DONE).* This could be the one using some ordinal
>> values calculated, or a more complex logic).
>> - the *builder supports adding property sources explicitly, or loading the
>> automatically registered at the end of the current chain (also not
>> performing any sorting implicitly)*. This also allows to define parts of
>> the configuration setup programmtically, but still using the default
>> loading logic for registered config sources. (DONE)
>>
>> *See Tamaya's ConfigurationContextBuilder as an example for this*. BTW the
>> *metamodel* module in Tamaya's sandbox basically is nothing more than an
>> *XML
>> based configuration that is backed by this kind of Builder apporach*. It
>> allows as well to add preregistered config sources, but also allows to
>> explicitly hard code property sources being added.
>>
>>
>> All items marked with *RED* are already implemented in the current Tamaya
>> head. So I was looking for a way to implement (2) in our API. Basically my
>> approach proposed would be:
>>
>> - Remove the *getOrdinal()* method from the *PropertySource*.
>> - Extend the existing *PropertySourceComparator* (this is the one
>> responsible for ordering the automatically loaded property sources on
>> startup by default) to implement the following logic:
>> - Check if the *PropertySource* provides an *int* convertible value
>> for the key *"tamaya.ordinal"*.
>> - Check via reflection for a *getOrdinal() *method.
>> - Check for a *@Priority* annotation's value.
>> - Use 0 as *default*.
>>
>> Overall the code change needed in all implementations would be to remove
>> the @Override annotation on any existing getOrdinal() method.
>>
>> Please discuss the idea: I am well aware that this equals to an API
>> change.
>> Is it worth? Or not?
>> Do you have better implementation alternatives/ideas?
>>
>> Thanks, J Anatole
>>
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Removing ordinals/getOrdinal()
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I have to think about it first...
Am 06.02.17 um 20:02 schrieb Anatole Tresch:
> Hi all
>
> In the microprofile.io group we are currently discussing and defining a
> minimalistic configuration API. Most of the things look quite compatible
> with out approach. Nevertheless I was also sharing my thaughts regarding
> the "ordinal concept" on my blog here,:
> https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-
> sources/
> <https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-sources/>
>
> *Quick Summary:*
>
> *I think ordinals have too many downsides and I consider them only as one
> implementation of a more wider concept: A mapping function of ConfigSources
> to a Configuration. *Even the fact that I have a well defined
> unidirectional tree of sources is a design decision. Even, when I define
> that a configuration value is determined by walking along a well ordered
> list of config sources, the ordering is not necessaRILY AUTOMATICALLY
> APPLIED:
> 1) When *using a Builder* for defining my Configuration, I *explicitly
> define my config source ordering.* NO AUTOMATISM AT ALL.
> *DONE*: In Tamaya this can be achieved by implementing the
> *ConfigProviderSpi*.
> 2) When *collecting config sources* as they are registered, *I can evaluate
> some ordinal for each of them to determine the order. This does not require
> the ordinal to be defined on the ConfigSource API, *I can access it as an
> ordinary config value from the Config Source.
> 3) When I have a use case, where I want to have an *additional criteria in
> place, with only ordinals I can get into an big mess.* Imagine I want to
> have my configuration sources not only ordered by their ordinal, but also
> by some other criteria, such as a grouing. E.g. there are use cases, where
> file based configuration must be handled differently than classpath based
> conifig, but there are also different priorities (default and explicit
> values) within each configuration group. In this case ordinals are not
> sufficient anymore and I end up with hyper complex logic to make these
> things working by wrapping everything, so I can define all ordinals as
> needed at the end of my ConfigSource collection phase. Nobody wants to do
> that.
>
> All these aspects can be solved by
> - defining a *Builder*, which *by default does not sort the sources added
> (DONE)*
> - let the builder *perform sorting on its config sources by passing the
> Comparator to be applied (DONE).* This could be the one using some ordinal
> values calculated, or a more complex logic).
> - the *builder supports adding property sources explicitly, or loading the
> automatically registered at the end of the current chain (also not
> performing any sorting implicitly)*. This also allows to define parts of
> the configuration setup programmtically, but still using the default
> loading logic for registered config sources. (DONE)
>
> *See Tamaya's ConfigurationContextBuilder as an example for this*. BTW the
> *metamodel* module in Tamaya's sandbox basically is nothing more than an *XML
> based configuration that is backed by this kind of Builder apporach*. It
> allows as well to add preregistered config sources, but also allows to
> explicitly hard code property sources being added.
>
>
> All items marked with *RED* are already implemented in the current Tamaya
> head. So I was looking for a way to implement (2) in our API. Basically my
> approach proposed would be:
>
> - Remove the *getOrdinal()* method from the *PropertySource*.
> - Extend the existing *PropertySourceComparator* (this is the one
> responsible for ordering the automatically loaded property sources on
> startup by default) to implement the following logic:
> - Check if the *PropertySource* provides an *int* convertible value
> for the key *"tamaya.ordinal"*.
> - Check via reflection for a *getOrdinal() *method.
> - Check for a *@Priority* annotation's value.
> - Use 0 as *default*.
>
> Overall the code change needed in all implementations would be to remove
> the @Override annotation on any existing getOrdinal() method.
>
> Please discuss the idea: I am well aware that this equals to an API change.
> Is it worth? Or not?
> Do you have better implementation alternatives/ideas?
>
> Thanks, J Anatole
>
>
--
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Removing ordinals/getOrdinal()
Posted by Werner Keil <we...@gmail.com>.
+1
The less intrusive approach sounds reasonable.
Although we decided to drop javax.annotations (e.g. some Embedded users did
not like the yet small overhead of another dependency) and a Java ME
compatible API won't allkow reflection at this point I think for a
Desktop/Server framework like Tamaya we can afford to offer both.
Making assumptions like
- ordinal 100 = web.xml
- ordinal 200 = JNDI
...
Sounds extremely restrictive at least for a more distributed solution.
I can't say which way Microprofile will go now, or if they replace it with
something else, but it does not intend to create a standard now, so Tamaya
is not forced to implement this public API at this point.
I just wrote a teaser article about Microprofile for DWX '17 (the German
speakers among you are welcome to take a look at a PDF if you want, I will
only point to the article when they release it) with proposed 1.1 features
for what loooks like between Q2 and the second half of 2017. Configuration
aims to simplify and unify the tons of different config approaches you see
between Wildfly, Websphere Liberty, TomEE, Glassfish/Payara or other
containers that may want to call themselves compatible. There are
Properties files, XML, JSON, YAML and probably even a few other
configuration methods. To get a common denominator between those is a key
goal Microprofile has to accomplish first. Ideally via some comfortable
mechanism like CDI annotations, but remote config servers are probably not
the first priority, so it may have slighly different goals. And once that
was archived, we shall probably see a "real standard" either led by Oracle
or another corporate JCP member like Red Hat or IBM. Inspired by this API
and a few others including Tamaya, Spring, Typesafe, Archaius or Commons
Config.
Regards,
Werner
On Mon, Feb 6, 2017 at 8:02 PM, Anatole Tresch <at...@gmail.com> wrote:
> Hi all
>
> In the microprofile.io group we are currently discussing and defining a
> minimalistic configuration API. Most of the things look quite compatible
> with out approach. Nevertheless I was also sharing my thaughts regarding
> the "ordinal concept" on my blog here,:
> https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-
> sources/
> <https://maketechsimple.wordpress.com/2017/01/04/composing-configuration-
> sources/>
>
> *Quick Summary:*
>
> *I think ordinals have too many downsides and I consider them only as one
> implementation of a more wider concept: A mapping function of ConfigSources
> to a Configuration. *Even the fact that I have a well defined
> unidirectional tree of sources is a design decision. Even, when I define
> that a configuration value is determined by walking along a well ordered
> list of config sources, the ordering is not necessaRILY AUTOMATICALLY
> APPLIED:
> 1) When *using a Builder* for defining my Configuration, I *explicitly
> define my config source ordering.* NO AUTOMATISM AT ALL.
> *DONE*: In Tamaya this can be achieved by implementing the
> *ConfigProviderSpi*.
> 2) When *collecting config sources* as they are registered, *I can evaluate
> some ordinal for each of them to determine the order. This does not require
> the ordinal to be defined on the ConfigSource API, *I can access it as an
> ordinary config value from the Config Source.
> 3) When I have a use case, where I want to have an *additional criteria in
> place, with only ordinals I can get into an big mess.* Imagine I want to
> have my configuration sources not only ordered by their ordinal, but also
> by some other criteria, such as a grouing. E.g. there are use cases, where
> file based configuration must be handled differently than classpath based
> conifig, but there are also different priorities (default and explicit
> values) within each configuration group. In this case ordinals are not
> sufficient anymore and I end up with hyper complex logic to make these
> things working by wrapping everything, so I can define all ordinals as
> needed at the end of my ConfigSource collection phase. Nobody wants to do
> that.
>
> All these aspects can be solved by
> - defining a *Builder*, which *by default does not sort the sources added
> (DONE)*
> - let the builder *perform sorting on its config sources by passing the
> Comparator to be applied (DONE).* This could be the one using some ordinal
> values calculated, or a more complex logic).
> - the *builder supports adding property sources explicitly, or loading the
> automatically registered at the end of the current chain (also not
> performing any sorting implicitly)*. This also allows to define parts of
> the configuration setup programmtically, but still using the default
> loading logic for registered config sources. (DONE)
>
> *See Tamaya's ConfigurationContextBuilder as an example for this*. BTW the
> *metamodel* module in Tamaya's sandbox basically is nothing more than an
> *XML
> based configuration that is backed by this kind of Builder apporach*. It
> allows as well to add preregistered config sources, but also allows to
> explicitly hard code property sources being added.
>
>
> All items marked with *RED* are already implemented in the current Tamaya
> head. So I was looking for a way to implement (2) in our API. Basically my
> approach proposed would be:
>
> - Remove the *getOrdinal()* method from the *PropertySource*.
> - Extend the existing *PropertySourceComparator* (this is the one
> responsible for ordering the automatically loaded property sources on
> startup by default) to implement the following logic:
> - Check if the *PropertySource* provides an *int* convertible value
> for the key *"tamaya.ordinal"*.
> - Check via reflection for a *getOrdinal() *method.
> - Check for a *@Priority* annotation's value.
> - Use 0 as *default*.
>
> Overall the code change needed in all implementations would be to remove
> the @Override annotation on any existing getOrdinal() method.
>
> Please discuss the idea: I am well aware that this equals to an API change.
> Is it worth? Or not?
> Do you have better implementation alternatives/ideas?
>
> Thanks, J Anatole
>
>
> --
> *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*
>