Hi! 1.1)
I think we agree that having a PropertySource/ConfigSource SPI with MANY implementations is the way to go? Any objections? 1.2) Where should it belong to? Is it an API or rather an SPI? I think it's more the later. A end user just likes to get the 'final' configured values and does NOT deal with the PropertySources himself. It is really just for extending the system -> SPI. 1.3) Merging. Option (1.3.a) Do we like to do 'implicit' merging (aka the ordinal stuff). Option (1.3.b) Or do we like 'explicit' (the merge function). What benefit does this add in practice? Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH ConfigSource (PropertySource) has an ordinal which it can set itself. The higher the configuration ordinal of the ConfigSource, the more important it is and it will override values from ConfigSources with lower ordinal. That way it is possible to have a kind of 'default configuration' e.g. in a property file inside your project and later overwrite it via -Dxxx=yyy, JNDI, or some container provided MyCountainerAdminConfigSource etc later. Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There was merge(String key, PropertySource s1, s2), but that would mean that every user needs to deal with that himself? Could you please elaborate on that option? I didn't get it... LieGrue, strub
