You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current design relies a lot on the Vault class static methods as main entry points for building vaults.
While it is possible to work with differentiated VaultParser instances, the current API design does not make it clear nor easy. As a result, the path of least resistance systematically leads to the registration of custom modules directly into the default parser, eventually through static blocks, which is far from ideal.
Instead, we should make it possible for the user to be able to assemble a VaultBuilder providing the exact same facilities as the Vault static methods.
if one wants an injectable vault setting, it is already possible, but they have to write the following, which I find particularly impractical:
//this would be done in the setup phase somewhere//requires knowledge of the inner workings (factory model, parser implementation)varfactory = newVaultFactory(newVaultCompositeParser()
.register(newMyCustomModule())
.registerPreprocessor(newMyCustomPreprocessor())
);
//verbose / unintuitive ; it does provide the tools for a multi-stage build howevervarbuilder = Vault.builder()
.setFactory(factory)
.with(
List.of(
"conf/first-conf.yml",
"conf/second-conf.yml"
),
variables(defs → defs.set("some_var", 123))
);
try (varvault = builder.build()) {
SomeServices = vault.instance(SomeService.class);
}
instead, we could enable the following pattern :
/* Some place where core configuration logic happens */VaultBuilderbuilder = Vault.builder(parser → parser
.register(newMyCustomModule())
.registerPreprocessor(newMyCustomPreprocessor())
);
/* Someplace else where we need to load a configuration graph */try (varvault = builder.with(
variables(defs → defs.set("some_var", 123)),
"conf/first-conf.yml",
"conf/second-conf.yml"
)) {
SomeServices = vault.instance(SomeService.class);
}
The text was updated successfully, but these errors were encountered:
Current design relies a lot on the
Vault
class static methods as main entry points for building vaults.While it is possible to work with differentiated
VaultParser
instances, the current API design does not make it clear nor easy. As a result, the path of least resistance systematically leads to the registration of custom modules directly into the default parser, eventually throughstatic
blocks, which is far from ideal.Instead, we should make it possible for the user to be able to assemble a
VaultBuilder
providing the exact same facilities as theVault
static methods.So just like we can currently do things like :
where, prior to this if we need a custom module and/or preprocessor we have to do something like :
if one wants an injectable vault setting, it is already possible, but they have to write the following, which I find particularly impractical:
instead, we could enable the following pattern :
The text was updated successfully, but these errors were encountered: