Should config validation ensure configured components are available?

[codeboten]

One question that came to mind as I was reviewing #26 is whether configuration validation should be responsible for validating that configured components are available. For example if I configure the xray propagator but the propagator is not available in my system, will configuration validation tell me this or will it load the config (assuming its configured properly) and let the SDK fail?

[svrnm]

what if there is a default (print a warning but just continue starting the app) but it can be overwriten with an additional property?

  propagators:
    - name: tracecontext
    - name: baggage
      failIfNotPresent: true

[jack-berg]

if I configure the xray propagator but the propagator is not available in my system, will configuration validation tell me this or will it load the config (assuming its configured properly) and let the SDK fail?

The java autconfigure component is responsible for parsing environment variables and configuring the SDK. It fails fast if a component like an exporter is referenced but is not available on the classpath.

You mention "will configuration validation tell me this or will it load the config", which supposes separate components for config validation and loading the config. If we do end up with a situation like that, I think the config validation phase should be limited to validating correct syntax, types, and at most simple validations that primitive options are valid (i.e. values are positive if an option only supports positive values). Additional validation like endpoint validation, presence of libraries on classpath, etc, is possible, but is a rabbit hole. I think its best to to perform more complex verification when parsing the config into an SDK instance, in the context of a real application.