How should AutoConfigurationCustomizer work when file configuration is used #6576
Description
AutoConfigurationCustomizer provides a very useful escape hatch allowing extension of autoconfigure with programmatic configuration when env vars / system properties do not suffice.
#6575 adds support to customize the parsed configuration model, and this is useful, but there still might be instances where the configuration model does not fully represent the set of configuration options which are available via programmatic config.
We're likely to need a way to restore this escape hatch in file configuration.
We could support the AutoConfigurationCustomizer SPI, but there are some drawbacks:
AutoConfigurationCustomizerinstances would be pulling double duty, working in both file configuration and non-file configuration scenarios. This may cause issues as implementations try to customize the SDK installation in ways that don't make sense with file configuration. For example, what doesAutoConfigurationCustomizer#addPropertiesSupplierdo in a file configuration scenario?- File configuration's
StructuredConfigPropertiesproperty holder is different than theConfigPropertiesproperty holder used inAutoConfigurationCustomizer, and it will be hard to resolve the differences in a way that makes sense.
We could introduce a new FileConfigurationCustomizer SPI with similar capabilities, with:
- Similar APIs as
AutoConfigurationCustomizer, but withStructuredConfigPropertiesinstead ofConfigProperties - Removal of any
AutoConfigurationCustomizerAPIs which don't make sense in a file configuration context (i.e.#addPropertiesCustomizer) - Add callback for customizing the configuration model and solve Add ability to programmatically customize configuration model when
otel.experimental.config.fileis set #6575 at the same time