Details
Minor Description
The config provider mechanism doesn't work if used for the plugin.path property of a standalone or distributed Connect worker. This is because the Plugins instance which performs plugin path scanning is created using the raw worker config, pre-transformation (see ConnectStandalone and ConnectDistributed).
Unfortunately, because config providers are loaded as plugins, there's a circular dependency issue here. The Plugins instance needs to be created before the DistributedConfig/StandaloneConfig is created in order for the config providers to be loaded correctly, and the config providers need to be loaded in order to perform their logic on any properties (including the plugin.path property).
There is no clear fix for this issue in the code base, and the only known workaround is to refrain from using config providers for the plugin.path property.
A couple improvements could potentially be made to improve the UX when this issue arises:
- Alter the config logging performed by the DistributedConfig and StandaloneConfig classes to always log the raw value for the plugin.path property. Right now, the transformed value is logged even though it isn't used, which is likely to cause confusion.
- Issue a WARN- or even ERROR-level log message when it's detected that the user is attempting to use config providers for the plugin.path property, which states that config providers cannot be used for that specific property, instructs them to change the value for the property accordingly, and/or informs them of the actual value that the framework will use for that property when performing plugin path scanning.
We should not throw an error on startup if this condition is detected, as this could cause previously-functioning, benignly-misconfigured Connect workers to fail to start after an upgrade.
Attachments
Issue Links
- links to