Codecov Report

Attention: Patch coverage is 97.87234% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.90%. Comparing base (2c0ee00) to head (8e9ab9f).
Report is 19 commits behind head on main.

@@             Coverage Diff              @@
##               main    #7453      +/-   ##
============================================
+ Coverage     89.82%   89.90%   +0.08%     
- Complexity     6998     7028      +30     
============================================
  Files           798      799       +1     
  Lines         21199    21248      +49     
  Branches       2055     2060       +5     
============================================
+ Hits          19041    19103      +62     
+ Misses         1496     1488       -8     
+ Partials        662      657       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

• Map<String, Object> DeclarativeConfigProperties#toMap(DeclarativeConfigProperties) convert any DeclarativeConfigProperties instance into a map representation using only the public API of the interface

Is this a way to treat declarative config like the old properties?
For this use case, my idea is to use https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-api-incubator/src/main/java/io/opentelemetry/instrumentation/api/incubator/config/internal/InstrumentationConfig.java, which is backed by DeclarativeConfigPropertiesBridge and allows access to structured properties where needed.

• T DeclarativeConfiguration#convertToModel(DeclarativeConfigProperties, Class<T>) convert any DeclarativeConfigProperties instance into an instance of a model class T by wrapping jackson's ObjectMapper.convertValue

great idea!

Some options include:

• Move T DeclarativeConfiguration#convertToModel(DeclarativeConfigProperties, Class<T>) to a utility method in the API, and include a compileOnly dependency on jackson. If instrumentations want to use the utility method, they must provide the jackson dependency.

I like that.

Is this a way to treat declarative config like the old properties?

No the map it spits out is an equivalent to the YAML node the DeclarativeConfigProperties node represents, with all the data structures retained. This test is informative of the behavior. This method is an intermediate step in the convertToModel method, which looks like: DeclarativeConfigProperties -> Map<String, Object> -> T model.

Alright I've done a bit of reorganizing:

• Promote the utility method to opentelemetry-api-incubator so its easy to access by instrumentation
• opentelemetry-api-incubator has a compileOnly dependency on jackson, such that users who want to leverage this convenience method need to provide the dependency on com.fasterxml.jackson.databind
• Rework method signature so that given a ConfigProvider, its super easy for an instrumentation library to get a config model: T InstrumentationConfigUtil#getInstrumentationConfigModel(ConfigModel, String instrumentationName, ObjectMapper, Class<T>)

Updated the PR description to reflect these changes.