Problem
ConfigPropertiesUtil was introduced as a deprecated compatibility helper in #15809, and we still have a small number of remaining usages.
The remaining usages are not all the same kind of problem:
- some are true library / library-autoconfigure flat-config compatibility
- some are old deprecated config-name cleanup
- some are instrumentation-api config compatibility, not library instrumentation
- some are really semconv follow-up work
Also, if we do not want to force standalone library users onto declarative config in 3.0 yet, then many of the remaining library usages should likely stay for now.
Current buckets
| Name |
Desc |
Who's in |
Recommended action |
| Library autoconfigure / standalone library flat-config compatibility |
Library or library-autoconfigure code paths that still read system properties / env vars so users can configure them without requiring declarative config or config-provider-backed OpenTelemetry. Removing these would effectively push standalone library users toward declarative config in 3.0. |
TracingRequestHandler (AWS SDK 1.11), AwsSdkTelemetryFactory legacy path (AWS SDK 2.2), JdbcInstrumenterFactory, OpenTelemetryDriver, ContextDataKeys, OpenTelemetryContextDataProvider |
Keep for now if the 3.0 direction is to avoid forcing standalone library users onto declarative config. Revisit later when/if we want to require DC-backed config for standalone library usage. |
| Old deprecated config-name cleanup |
Support for older deprecated property names or aliases that already have replacements. This is different from the broader question of whether libraries may continue to use flat config at all. |
Deprecated JDBC fallback for old property names in JdbcInstrumenterFactory together with the replacement/deprecation handling in DbConfig (for example otel.instrumentation.common.db-statement-sanitizer.enabled) |
Remove in 3.0, gated on v3 preview flag in #18934. |
| instrumentation-api: flat-config compatibility |
These are in instrumentation-api, not library instrumentation. They already use config-provider-backed config when available and only fall back to flat-property reads for compatibility with plain OpenTelemetry. Autoconfigure+bridge users are covered by the bridge mappings in ConfigPropertiesBackedDeclarativeConfigProperties, but programmatic OpenTelemetry users (no autoconfigure, no DC) have no other path to configure these properties. |
InstrumenterBuilder (span suppression strategy), SemconvExceptionSignal (exception signal config) |
Keep in 3.0. Removing the flat fallback would silently break programmatic users with no migration path. |
| Semconv config evolution |
Active semconv follow-up work, tracked in #18907. |
SemconvStability |
See #18907. |
Suggested scope for this issue
If the goal for 3.0 is not to force standalone library users onto declarative config yet, then the scope of this issue should likely be narrowed to:
- removing truly obsolete / already-deprecated old-name compatibility
- identifying library usages we intentionally keep for now
- discussing the span suppression compatibility question here, even if any implementation happens separately
- splitting semconv follow-up into separate work
Follow-up work
- Semconv config evolution is tracked in #18907
- 3.0 cleanup of deprecated old property-name compatibility where replacements already exist
Problem
ConfigPropertiesUtilwas introduced as a deprecated compatibility helper in #15809, and we still have a small number of remaining usages.The remaining usages are not all the same kind of problem:
Also, if we do not want to force standalone library users onto declarative config in 3.0 yet, then many of the remaining library usages should likely stay for now.
Current buckets
OpenTelemetry. Removing these would effectively push standalone library users toward declarative config in 3.0.TracingRequestHandler(AWS SDK 1.11),AwsSdkTelemetryFactorylegacy path (AWS SDK 2.2),JdbcInstrumenterFactory,OpenTelemetryDriver,ContextDataKeys,OpenTelemetryContextDataProviderJdbcInstrumenterFactorytogether with the replacement/deprecation handling inDbConfig(for exampleotel.instrumentation.common.db-statement-sanitizer.enabled)instrumentation-api, not library instrumentation. They already use config-provider-backed config when available and only fall back to flat-property reads for compatibility with plainOpenTelemetry. Autoconfigure+bridge users are covered by the bridge mappings inConfigPropertiesBackedDeclarativeConfigProperties, but programmaticOpenTelemetryusers (no autoconfigure, no DC) have no other path to configure these properties.InstrumenterBuilder(span suppression strategy),SemconvExceptionSignal(exception signal config)SemconvStabilitySuggested scope for this issue
If the goal for 3.0 is not to force standalone library users onto declarative config yet, then the scope of this issue should likely be narrowed to:
Follow-up work