Configuration Category vs package naming

[Mark Struberg]

And yet more lessons and discussions from Apache DeltaSpike.

In DeltaSpike we started with a 1-for-all configuration. And we still have this until now.

Means if a user likes to have different (totally unrelated) areas in his application where he needs configuration then he needs to use a String prefixing mechanism to tell those apart. 

E.g. 

projectA.dbconfig.url

projectA.dbconfig.host

vs 

someotherpart.archive.url

someotherpart.archive.authentication=BASIC

The impact which might be not so clear is when it comes to own 'ConfigSources'. The always serve ALL configurations. So even if you add a ConfigSource(s) for "dbconfig.properties" it could technically contain values for the archive subsystem as well. The same accounts for "archive.properties".

Of course, there are ConfigSources which are hard to split. like the database, JNDI, System.env, Sytem.properties,...

We could also define a DEFAULT_CONFIG_CATEGORY which all ConfigSources belong to if they don't explicitly handle a specific one. The search path would then consist of all the default_category ConfigSources plus the specific ones for the selected category.

Another thing related to subpackaging is how we like to configure environment specific [1] or ProjectStage specific [2][3] overrides . In DeltaSpike we simply leverage subpackages for this as well.

LieGrue,

strub

[1] https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java#L227

[2] http://deltaspike.apache.org/projectstage.html

[3] https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java#L185