Hi Anatole!
First of all thanks for sharing this sample. You might know your use cases but
others don't.
I assume that all this PropertySource construction is done at a single point,
e.g. a producer metho
Let me ask a few questions:
1.) How do you know which ConfigSources exist in the project? You might be one
jar in a dozen ones, having no control over them?
2.) In DeltaSpike each property file could define it's own ordinal with a
simple entry in the property file. That way you can just add a JAR which
overrides a default config from another jar. Would each of them get an own
name? Or do they all share the same name and priority?
3.) How do you deal with modularity? E.g. adding a dependency which needs some
other ConfigSource but knows nothing about your code?
4.) Another modularity question: What about having multiple jars (different
independent framework parts) and each of them likes to have another
PropertySouceBuilder configuration?
5.) How do you allow containers and framework programmers to add
PropertySources which affect all the project?
6.)
> - you can override along the classloader hierarchy (system, ear, war)
> by adding resources to the classpath at xxx.Usually this does not work well
> as e.g. all the JARs in WEB-INF/lib have exactly the same 'level'. It's
> totally up to the ClassLoader mechanism in which order you get them. And that
> could change on every restart. Been there, done that - doesn't work.
7.)
> In code the do simply: Configuration config =
> Configuration.current("Stephen");
And what if another jar does Configuration.current("Giovanni")?
Imo that approach doesn't scale.
I like to align our ideas, so I enumerate my main goals and design principles
of a config system as I envision it:
A.) have a total separation between the configuration system and it's
consumers. The 'consumers' API should not know where the result comes from and
also not what the value is. I think this is the only way we can provide an
extensible system where e.g. the Operations team could 'overwrite' certain
values. If we require the userland code to know about the PropertySources then
we cannot do this.
B.) Have a flexible SPI to allow Container Vendors and also application
programmers to add their own PropertySources in a very easy way.
C.) The SPI should be extensible via plugin mechanism. If a jar containing a
PropertySource gets added then it should automatically get picked up for this
very application.
Are we on the same page here?
LieGrue,
strub
> On Saturday, 27 December 2014, 15:35, Anatole Tresch <[email protected]>
> wrote:
> > Hi Gerhard
>
> all you say is true here, I also will not provide every kind of combination
> logic, but I want to have a mechanism that is capable enough.
>
> @Mark end users don't see this mechanisms here. It used by the power users,
> which define the "metamodel" how/where configuration is read
> and assembled, e.g.
>
> SPI: PropertySourceProvider {
> Collection<PropertySource> getPropertySources();
> }
>
> Lets assume the provider is returning one property source named
> "Stephen".
> The power user would then probably write something like that:
>
> PropertySource src =
> PropertySourceBuilder.of("Stephen").addProviders(myProv2,
> myProv3).withAggregationPolicy(mySpecialPolicy)
>
> .addProvider(BranchSpecificOverrideFilter.getPropertySource()).withAggregationPolicy(AggregationPolicy.OVERRIDE_AND_LOG)
> .addProvider(DefaultJavaEEProviders.getEarProvider()).build();
>
> This src instance then is returned e.g. by the provider (could also be
> contextually per classloader etc.). So it is not only that the mechanism is
> much more explicit and powerful, it
> is also easier to understand. There is exactly one location, where all
> happens: the PropertySourceProvider. You look at the code and immediately
> now, what is happening.
> So the code that is assembling the final property source returned is under
> full control of the users and nicely explicit.
>
> For normal users the mechanism is completely transparent the will typically
> have some kind of documentation, where its written:
>
> - put your config files in the formats .ini or .xml at the location xy
> - you can override along the classloader hierarchy (system, ear, war) by
> adding resources to the classpath at xxx.
> - Branch sepcific overrides are merge automatically into it, see chapter
> 3.4 for additional details.
> - Finally it is possible to override entries an system leven, by setting
> according system properties.
>
> In code the do simply: Configuration config =
> Configuration.current("Stephen");
>
> You get it?
>
>
>
> 2014-12-27 15:13 GMT+01:00 Gerhard Petracek <[email protected]>:
>
>> hi anatole,
>>
>> i guess everybody agrees that overriding based on ordinals wouldn't be
>> enough for every possible use-case.
>> back then we had a long discussion about it. we ended up with adding a
>> simple (and optional) ConfigFilter interface.
>>
>> @aggregation:
>> aggregation of key/value pairs is supported implicitly by an ordinal based
>> approach.
>> aggregation of values >per key< can be done manually with an own
>> config-source (which delegates to the others and only aggregates those
>> results).
>> yes - that way this use-case is more complicated out-of-the-box. however,
>> imo if users (think they) need such a complicated config, they should also
>> need to do a bit more for it.
>> (i guess in several cases they might question the requirement before they
>> continue...)
>>
>> in general about possible use-cases (and features):
>> we can never address everything out-of-the-box.
>> a nice example is bean-validation. i could list a lot of cases which
> aren't
>> possible with that api/spi out-of-the-box, however, for the majority
> it's
>> good enough.
>> i saw several users who couldn't replace their existing
> validation-approach
>> (as it was).
>> however, several of them just simplified their validation-logic and were
>> still happy about the result.
>> others extended bv e.g. via the spi and only few kept what they used before
>> (e.g. because it wasn't possible with bv or the workaround was too
>> complicated
>> and they insisted on what they had).
>>
>> regards,
>> gerhard
>>
>>
>>
