<commit_before># Dropwizard Configstack

This is the open-source version of some code I wrote to make
configuration with Dropwizard more manageable. What I missed the most
was, in no particular order:

* A base, shared config with overrides and/or mix-ins for various
  purposes and environments - stackable configs!
* Variable substitutions like `${this}`, which can reference other
  parts of the config as well, like
  `${/server/applicationConnectors/0/type}`.  Give me one reason we
  shouldn't have that.
* Resources that are loadable from files as usual, but with
  fallbacks to classpath resources.

Dropwizard's config support already does much of this - except stacks -
but not in ways that combine easily.

## Simple usage

This is a Dropwizard bundle, so you know how to use it already.

It has a builder object – in this case a bundler, of course:

```java
bootstrap.addBundle(
    new ConfigStackBundler<>(MyConfiguration.class)
        .enableClasspathResources()
        .enableVariableReplacements()
        .bundle());
```


### Resolution

This is a default configuration that figures out what you want to load
by looking the arguments to the wizard's `server` command, e.g. suppose
you say :

```
server misc,debug
```

This will load the following resources from classpath or the file
system, assuming they exist, and stack them:

```
MyConfiguration.json
MyConfiguration-misc.json
MyConfiguration-debug.json
```

YAML resources are checked too, so if, say, the following resources
exist, they will be found and loaded too:

```
MyConfiguration.json
MyConfiguration-misc.yaml
MyConfiguration-debug.yaml
```

Finally, if the paths do exist as file names, they will be loaded in
preference to whatever is on the classpath. In general, we
check the bootstrap's existing config source provider for any data
first, then proceed to check the classpath.

### Replacements

If any values are ``${subsitutable}``, they will be looked-up and
substituted with values from the following sources:

1. System properties
1. Environment properties
1. The config itself (using JSON pointer syntax)

## Advanced usage

### Common base config

The bundler takes a common-config argument, which will be loaded
first of all. This is a nice way to enforce some core settings across
many applications – consistent logging springs to mind:

```java
bootstrap.addBundle(
    new ConfigStackBundler<>(StackAppConfiguration.class)
        .addCommonConfig( "common-config")
        .enableClasspathResources()
        .enableVariableReplacements()
        .bundle());
```

Now our simple example will include:

```
common-config.yaml
MyConfiguration.json
MyConfiguration-misc.json
MyConfiguration-debug.json
```<commit_msg>README a bit more.<commit_after># Dropwizard Configstack

This is the open-source version of some code I wrote to make
configuration with Dropwizard more manageable. What I missed the most
was, in no particular order:

* A base, shared config with overrides and/or mix-ins for various
  purposes and environments - stackable configs!
* Variable substitutions like `${this}`, which can reference other
  parts of the config as well, like
  `${/server/applicationConnectors/0/type}`.  Give me one reason we
  shouldn't have that.
* Resources that are loadable from files as usual, but with
  fallbacks to classpath resources.

Dropwizard's config support already does much of this - except stacks -
but not in ways that combine easily.

## Simple usage

This is a Dropwizard bundle, so you know how to use it already.

It has a builder object – in this case a bundler, of course:

```java
bootstrap.addBundle(
    new ConfigStackBundler<>(MyConfiguration.class)
        .enableClasspathResources()
        .enableVariableReplacements()
        .bundle());
```


### Resolution

This is a default configuration that figures out what you want to load
by looking the arguments to the wizard's `server` command, e.g. suppose
you say :

```
server misc,debug
```

This will load the following resources from classpath or the file
system, assuming they exist, and stack them:

```
MyConfiguration.json
MyConfiguration-misc.json
MyConfiguration-debug.json
```

YAML resources are checked too, so if, say, the following resources
exist, they will be found and loaded too:

```
MyConfiguration.json
MyConfiguration-misc.yaml
MyConfiguration-debug.yaml
```

Finally, if the paths do exist as file names, they will be loaded in
preference to whatever is on the classpath. In general, we
check the bootstrap's existing config source provider for any data
first, then proceed to check the classpath.

### Replacements

If any values are ``${subsitutable}``, they will be looked-up and
substituted with values from the following sources:

1. System properties
1. Environment properties
1. The config itself (using JSON pointer syntax)

## Advanced usage

### Common base config

The bundler takes a common-config argument, which will be loaded
first of all. This is a nice way to enforce some core settings across
many applications – consistent logging springs to mind:

```java
bootstrap.addBundle(
    new ConfigStackBundler<>(StackAppConfiguration.class)
        .addCommonConfig("common-config")
        .enableClasspathResources()
        .enableVariableReplacements()
        .bundle());
```

Now our simple example will include:

```
common-config.yaml
MyConfiguration.json
MyConfiguration-misc.json
MyConfiguration-debug.json
```
{'fraction_non_alphanumeric': 0.07300478116954763, 'fraction_numerical': 0.001471129091577786, 'mean_word_length': 4.2908560311284045, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2509501', 'n_tokens_mistral': 1458, 'n_tokens_neox': 1401, 'n_words': 674}