Add Roadmap

[remmeier]

a roadmap resp. pending features would be great. Some things that do come into my mind:

1. Reloading
2. Consul, etc.
3. Java 8 defines a configuration API. Would be great to have compatibility with that.
4. default methods
5. cascading like in netflix archaius (zone, data center, location specific configuration)

and to some degree it would be good to compare this feature set to other configurations out there (to be sure this one is the one worthwhile to use...)

[fabriziocucci]

@remmeier thanks for this. I agree with you, both a roadmap and a comparison matrix are in order.

Regarding your list of items:

1. Reloading

I've spent some time in the past thinking about an API for this but then I had to lower the priority. But I agree with you that it should be part of yacl4j. I'll open a task for this to make sure it gets tracked.

2. Consul, etc.

I guess all extensions will be added on a per-request basis. I've noticed that the Consul one is pretty popular and I don't think it will be hard to implement.

3. Java 8 defines a configuration API. Would be great to have compatibility with that.

Sounds interesting! I'm not aware of this new API, could you please provide a link?

4. default methods

Are you referring to Java 8 default methods for providing default values of configuration defined through interfaces? If that's the case, see this Jackson issue for an update on the subject.

5. cascading like in netflix archaius (zone, data center, location specific configuration)

As with the reloading API, also this one is on my "mental" roadmap by quite some time. I didn't look specifically at Archaius before but I did look at Spring Boot's profiles and Cfg4j's environments as good examples. But I'll open a task for this too.

[remmeier]

Regarding JEE8, seems that I was mistaken. It was planned but did not make it. It is however in the competing/complementing/... MicroProfile standard. e.g. https://www.ibm.com/support/knowledgecenter/en/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/cwlp_microprofile_overview.html.

resp. https://github.com/eclipse/microprofile-config

I do have an implementation for cascading for cfg4j, that could be ported if it is a match. Archius seems quite a bit more advanced compared to Spring Boot. Altough the implementation is a bit of a mess with that v1/v2 version. cfg4j is fairly broken in this area.

Consul could be ported from cfg4j as it makes use of the same license.

[fabriziocucci]

resp. https://github.com/eclipse/microprofile-config

It looks interesting, even though there are a couple of API design choices I don't particularly agree with. Ultimately, I think an extension supporting this API is feasible.

I do have an implementation for cascading for cfg4j, that could be ported if it is a match.

Is it public? I could have a look to have a better idea.

Consul could be ported from cfg4j as it makes use of the same license.

I agree, it seems the easiest way to go.

[remmeier]

As an extension would be great. I guess would also give a bit of traction by support a standard (if one considers micro-profile being a standard).

No, not public so far. But it looks like:

ConfigFilesProvider filePaths = () -> cascadingStrategy.generate(FILE_PREFIX, environment).stream()
	.map(it -> it + FILE_SUFFIX).map(Paths::get).collect(Collectors.toList());
SystemPropertiesConfigurationSource systemPropertiesSource = new SystemPropertiesConfigurationSource();		
EnvironmentVariablesConfigurationSource envVariablesSource = new EnvironmentVariablesConfigurationSource();
FilesConfigurationSource filesSource = new FilesConfigurationSource(filePaths);
ClasspathConfigurationSource classPathSource = new ClasspathConfigurationSource(filePaths);

and

/**
 * Strategy for determining a set of cascading resource names.  The strategy will resolve
 * a single resource name into an ordered list of alternative names.
 * 
 * For example, a strategy may specify that additional configuration files may be loaded
 * based on environment and datacenter.  The strategy will return the list,
 * 
 * basename
 * basename-${environment}
 * basename-${datacenter}
 * basename-$[environment}-${datacenter}
 */
@FunctionalInterface
public interface CascadeStrategy {

	/**
	 * Resolve a resource name to multiple alternative names.
	 * 
	 * @param baseName base name that gets suffixed 
	 * @param environment to cascade.
	 * 
	 * @return List of all names including the original name
	 */
	List<String> generate(String baseName, Environment environment);
}

Setup can obviously be simplified, mainly limited by cfg4j.

An environment may include zone, region, name, component and allow config file with a permutation thereof.