All, Alasdair Hodge recently contributed support for "externalised configuration", where a blueprint can indicate that a value is to be loaded from an external store rather than being coded directly. This is particularly useful to prevent plain-text passwords being placed in blueprints, but it has many uses.
It's not valid outside of blueprints however. I would like to be able to use it on configuration stored in brooklyn.properties. I've been investigating options for doing this and I would like to share what I have discovered and see what the consensus is for how to implement this. *Where to implement it* brooklyn.properties is loaded by the BrooklynProperties class (surprisingly). On first inspection this would be a good place to resolve the configuration; however resolving the configuration requires a reference to a management context, which this class doesn't have. In fact resolving the configuration at this stage is actually impossible, because the configuration resolvers are configured in brooklyn.properties! Therefore you must have loaded brooklyn.properties, and configured a management context, before you can resolve the configuration. My next attempt was to implement it in the constructor of AbstractManagementContext - at the end of the constructor (crucially, after brooklyn.properties has been loaded, and the external config supplier registry has been set), the configMap is transformed and all config resolved. This does appear to be usable. *How to refer to external config* In the YAML blueprints this is relatively easy, as there is already a framework for parsing the YAML and a DSL that can be extended to add the new configuration lookup. For brooklyn.properties there is no such thing - every property value is a string literal. Ideally we'd use the same DSL as the YAML parser, but this could be a complex solution, since the DSL parser is embedded into the deployment plan parser. We could write a new parser, but that seems to be over-complicated. For the moment I have taken a very simple approach - if the property value matches *in its entirety* "$brooklyn:external:supplierName:keyName" then an external config key will be made. This seems to be working. It's familiar to the DSL user, but it's also different enough that it could cause confusion. It's also not really flexible enough - it can replace the *whole* value with something looked up from storage, but it's not possible to mix plain text with multiple lookups, as could be done in YAML. What do people think? Thanks Richard.
