The need for ordering IMO is a fact. *The question is if the ordinal
concept is the best and single one to define an order.*
PROs:
- simple
- allows comparing of multiple property sources without knowing them
- overridable by config entries itself per property source
CONTRAs:
- what to do with multiple sources with the same ordinal
- what is the exact semanic of an ordinal
- what to do of a simple ordinal is not matching your requirements
- how to add a source between subsequent ordinals n and n+1
- when using builders to define your configs, ordinals are not
necessary, or even confusing, since ordinal values do not match the
effective order in place.
My current opinion is that ordinals are not a sufficient way to define an
ordering, but only one way of defining an order. Therefore ordinals should
not be part of a PropertySource's API. Assembling your config runtime in
XML, as well as using a builder do not need any ordinals, there are even
confusing, if present:
*XML:*
<tamaya-config>
<sources>
<source type="sys-properties" />
<source type="env-properties" />
<source type="etcd" />
</sources>
</tamaya-config>
*Builder:*
ConfigurationContextBuilder builder = ConfigurationProvider
.createConfigurationContextBuilder();
builder.addPropertySources(
*new* SystemPropsPropertySource(),
*new* EnvironmentPropsPropertySource(),
*new* EtcdPropertySource(),
);
Configuration config =
ConfigurationProvider.createConfiguration(builder.build());
For *XML based variant is currently in development/evaluation in Tamaya's
sandbox's metamodel module*, whereas the *builder based approach is a core
functionality* (in fact the xml model is built on top of the builder
pattern).
*Supporting Ordinals*
If someone still want to use an ordinal based approach, the ordinal can be
accessed as a normal property:
PropertyValue ordinal = propertySource.get("_ordinal");
Since ordinals may not be the single and only property to define a fixed
ordering, the current builder supports applying different Comparator as
needed to establish the ordering of property sources, so we could adapt the
example above and write the following to* use a (default) ordinal based
approach*:
ConfigurationContextBuilder builder = ConfigurationProvider
.createConfigurationContextBuilder();
builder.addPropertySources(
*new* SystemPropsPropertySource(),
*new* EnvironmentPropsPropertySource(),
*new* EtcdPropertySource(),
);
builder.sortPropertySources(DefaultPropertySourceComparator.getInstance());
Configuration config =
ConfigurationProvider.createConfiguration(builder.build());
If we want to *apply a different ordering* this can be achieved by applying
your custom comparator implementation:
Comparator<PropertySource> myCustomComparator = ...;
...
builder.sortPropertySources(myCustomComparator);
This way the API is more flexible, but still simple and does not mix-in an
ordinal concept, where it is not needed IMO.
My 50 cents.
J Anatole
2017-01-03 14:42 GMT+01:00 Werner Keil <[email protected]>:
> Hi,
>
> I though I'll start a new thread on this.
>
> As we spoke about the ordinal yesterday, this must be where Mark and
> DeltaSpike must have got this from in the first place;-)
> http://stackoverflow.com/questions/40944064/spring-
> boot-change-the-order-of-the-propertysource
>
> So the general idea existed e.g. in Spring for some time.
>
> Maybe if somebody has time and interest they could have a look at e.g. how
> something similar in Archaius can be archived for something like
> ConcurrentCompositeConfiguration.
>
> I could not see a notion of ordering, but should someone combine etcd with
> Zookeeper and one or more local sources, there should be some way of
> ordering and prioritising them.
>
> Werner
>
--
*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*
