DeclarativeConfigProperties: no way to coerce types without triggering warnings

[trask]

From open-telemetry/opentelemetry-java-instrumentation#15775 (comment)

Problem

YamlDeclarativeConfigProperties logs WARNING-level messages when a getter is called for a type that doesn't match the stored value:

WARNING: Ignoring value for key [foo] because it is Long instead of String

This means we can't build a type-coercing DeclarativeConfigProperties decorator without producing invalid warnings.

Use case

The Spring Boot starter populates OpenTelemetry's declarative config YAML from Spring's property system. Spring flattens its own YAML into key-value pairs and resolves ${} placeholders via Environment.getProperty(), which always returns String. These flat string properties are then converted back into a nested map and fed to Jackson's ObjectMapper.convertValue() to produce an OpenTelemetryConfigurationModel, which ultimately backs a YamlDeclarativeConfigProperties.

The problem is that the resulting types are inconsistent:

• Values from plain YAML (e.g. int_key: 42) are stored as their native types (Integer, Boolean, Double)
• Values resolved through Spring placeholders (e.g. int_key: ${INT_ENV:42}) arrive as String ("42")

We'd like to use a type-coercing decorator around DeclarativeConfigProperties to handle both cases transparently, but there is no way to check the actual stored type without triggering the WARNING-level logs, e.g.

• Calling delegate.getString("int_key") on a natively-typed Integer logs: "Ignoring value for key [int_key] because it is Integer instead of String"

[jack-berg]

Values resolved through Spring placeholders (e.g. int_key: ${INT_ENV:42}) arrive as String ("42")

I don't understand this. This should resolve as a tag:yaml.org,2002:int:

• https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/data-model.md#environment-variable-substitution
• https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/incubator/src/test/java/io/opentelemetry/sdk/extension/incubator/fileconfig/DeclarativeConfigurationParseTest.java#L1045

Are you talking about the spring function "Spring flattens its own YAML into key-value pairs and resolves ${} placeholders via Environment.getProperty(), which always returns String."?

We'd like to use a type-coercing decorator

What's a type-coercing decorator?

but there is no way to check the actual stored type without triggering the WARNING-level logs, e.g.

I'm supported of adding more introspection APIs. Currently we have Set<String> getPropertyKeys(). Some options to improve:

• Class<?> getType(String key): return the type of a given key
• boolean is<Type>(String key) (e.g. boolean isString(String key)): boolean checks for each type

[trask]

Values resolved through Spring placeholders (e.g. int_key: ${INT_ENV:42}) arrive as String ("42")

I don't understand this. This should resolve as a tag:yaml.org,2002:int

sorry for confusion, above statement is about Spring YAML (not OpenTelemetry YAML)

What's a type-coercing decorator?

e.g. we want to implement ConfigProvider so that calls to DeclarativeConfigProperties.getInt() automatically coerce Strings to Ints where possible

[Tusharika725]

@trask @jack-berg I would love to pick this up as my next issue!

To allow for safe type-coercion without triggering the WARNING logs, adding introspection APIs makes perfect sense. Between Jack's two proposals:

Class<?> getType(String key)
boolean is(String key) (e.g., isString(), isInteger())

Is there a preference from the maintainer team on which approach aligns better with the current DeclarativeConfigProperties design? Once there is consensus on the preferred method signature, I'm happy to open a PR adding it to the interface and implementing it across the backing classes!