Spring starter declarative config #14062

zeitlinger · 2025-06-18T16:13:15Z

otelbot-java-instrumentation · 2025-06-18T16:19:13Z

🔧 The result from spotlessApply was committed to the PR branch.

zeitlinger · 2025-06-19T17:48:25Z

@laurit can you help me figure out what the problem is?

AgentInstrumentationTest > classPathSetUp() FAILED	
    java.lang.NoClassDefFoundError: io/opentelemetry/sdk/autoconfigure/spi/ConfigProperties	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:348)	
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:328)	
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:264)	
        at instrumentation.AgentInstrumentationTest.classPathSetUp(AgentInstrumentationTest.java:53)

zeitlinger · 2025-06-20T06:20:26Z

@laurit can you help me figure out what the problem is?

AgentInstrumentationTest > classPathSetUp() FAILED	
    java.lang.NoClassDefFoundError: io/opentelemetry/sdk/autoconfigure/spi/ConfigProperties	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:348)	
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:328)	
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:264)	
        at instrumentation.AgentInstrumentationTest.classPathSetUp(AgentInstrumentationTest.java:53)

tried to fix that with cbb070b

laurit · 2025-06-20T12:35:14Z

@laurit can you help me figure out what the problem is?

AgentInstrumentationTest > classPathSetUp() FAILED	
    java.lang.NoClassDefFoundError: io/opentelemetry/sdk/autoconfigure/spi/ConfigProperties	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:348)	
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:328)	
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)	
        at java.lang.Class.forName0(Native Method)	
        at java.lang.Class.forName(Class.java:264)	
        at instrumentation.AgentInstrumentationTest.classPathSetUp(AgentInstrumentationTest.java:53)

tried to fix that with cbb070b

DeclarativeConfigPropertiesBridge is in boot loader but it depends on io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties that is not in boot loader

zeitlinger · 2025-06-20T13:05:38Z

DeclarativeConfigPropertiesBridge is in boot loader but it depends on io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties that is not in boot loader

I can't figure out what change could have caused that.

Is the solution to not used ConfigProperties in the agent config?

zeitlinger · 2025-06-20T13:11:53Z

DeclarativeConfigPropertiesBridge is in boot loader but it depends on io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties that is not in boot loader

I can't figure out what change could have caused that.

Is the solution to not used ConfigProperties in the agent config?

Let's see if it's 7116de1

laurit · 2025-06-20T13:26:50Z

Let's see if it's 7116de1

I don't think this is going to help. javaagent-extension-api belongs to boot loader, any class you are going to use there also needs to be in boot loader. Since based on that DeclarativeConfigPropertiesBridge needs to be in boot loader, it implements io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties that is not in boot loader, and shouldn't be there. Based on that I'd say the design is broken and needs to be rethought.

zeitlinger · 2025-06-20T13:31:11Z

Let's see if it's 7116de1

I don't think this is going to help. javaagent-extension-api belongs to boot loader, any class you are going to use there also needs to be in boot loader. Since based on that DeclarativeConfigPropertiesBridge needs to be in boot loader, it implements io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties that is not in boot loader, and shouldn't be there. Based on that I'd say the design is broken and needs to be rethought.

Why is it not failing on main? DeclarativeConfigPropertiesBridge is not changed (unless I miss something)

laurit · 2025-06-20T13:50:47Z

Why is it not failing on main? DeclarativeConfigPropertiesBridge is not changed (unless I miss something)

Because on main you don't have it in boot loader. Actually I was wrong about javaagent-extension-api belonging to boot loader. During agent packaging some of it is moved to boot loader and other parts are moved to agent loader. See

opentelemetry-java-instrumentation/javaagent/build.gradle.kts

Line 63 in 3d8ed9f

bootstrapLibs(project(":javaagent-extension-api")) {

and

opentelemetry-java-instrumentation/javaagent/build.gradle.kts

Line 147 in 3d8ed9f

    
           // exclude the agent part of the javaagent-extension-api; these classes will be added in relocate tasks

and

opentelemetry-java-instrumentation/javaagent/build.gradle.kts

Line 432 in 3d8ed9f

// exclude the bootstrap part of the javaagent-extension-api

I'd try excluding the bridge in

opentelemetry-java-instrumentation/javaagent/build.gradle.kts

Line 69 in 3d8ed9f

exclude("io.opentelemetry", "opentelemetry-sdk-extension-autoconfigure-spi")

zeitlinger · 2025-06-20T15:50:32Z

I'd try excluding the bridge in

opentelemetry-java-instrumentation/javaagent/build.gradle.kts

Line 69 in 3d8ed9f

exclude("io.opentelemetry", "opentelemetry-sdk-extension-autoconfigure-spi")

That worked - thanks a lot!

otelbot-java-instrumentation · 2025-06-30T09:36:21Z

🔧 The result from spotlessApply was committed to the PR branch.

...io/opentelemetry/instrumentation/spring/autoconfigure/SpringDeclarativeConfigProperties.java

...lemetry/instrumentation/spring/autoconfigure/internal/resources/DistroComponentProvider.java

...io/opentelemetry/instrumentation/spring/autoconfigure/SpringDeclarativeConfigProperties.java

.../src/main/java/io/opentelemetry/instrumentation/spring/autoconfigure/EmbeddedConfigFile.java

zeitlinger · 2025-11-11T09:00:43Z

@laurit thanks for the review! please check again 😄

.../src/main/java/io/opentelemetry/instrumentation/spring/autoconfigure/EmbeddedConfigFile.java

...io/opentelemetry/instrumentation/spring/autoconfigure/SpringDeclarativeConfigProperties.java

laurit · 2025-11-14T13:57:13Z

docs/apidiffs/current_vs_latest/opentelemetry-spring-boot-autoconfigure.txt

+++  NEW CLASS: PUBLIC(+) io.opentelemetry.sdk.extension.incubator.fileconfig.DeclarativeConfigurationAccess  (not serializable)
+	+++  CLASS FILE FORMAT VERSION: 52.0 <- n.a.
+	+++  NEW SUPERCLASS: java.lang.Object
+	+++  NEW METHOD: PUBLIC(+) STATIC(+) com.fasterxml.jackson.databind.ObjectMapper getObjectMapper()


This is not ideal. I think we should just copy how ObjectMapper is constructed for now and revisit this after the release. Perhaps there is a way to write a test that would ensure that we have configured the mapper the same way as in the sdk or perhaps we can convince the sdk maintainers to move it into an internal class.
Also this trick will probably break for people who use jdk modules because of the split package. Idk whether that is relevant.

Does it make sense to revert to the reflective access that I had before? This is not performance critical after all?

I'll copy the ObjectMapper config for now - so that we can discuss that separately as you suggested.

perhaps we can convince the sdk maintainers to move it into an internal class

Created open-telemetry/opentelemetry-java#7843

Perhaps there is a way to write a test that would ensure that we have configured the mapper the same way as in the sdk

This is already tested indirectly in the smoke test, which failed without those settings.

This reverts commit 5476821.

zeitlinger self-assigned this Jun 18, 2025

github-actions bot added the test native This label can be applied to PRs to trigger them to run native tests label Jun 18, 2025

zeitlinger marked this pull request as ready for review June 19, 2025 16:09

zeitlinger requested a review from a team as a code owner June 19, 2025 16:09

zeitlinger force-pushed the spring-starter-declarative-config branch 2 times, most recently from 17d949a to f81444f Compare June 19, 2025 16:57

zeitlinger added this to Declarative Configuration: Java Jun 20, 2025

zeitlinger removed this from Declarative Configuration: Java Jun 20, 2025

zeitlinger mentioned this pull request Jun 20, 2025

Vendor specific instrumentation config options handling #14016

Merged

zeitlinger mentioned this pull request Jun 20, 2025

Internal telemetry always uses GlobalOpenTelemetry when declarative config is used open-telemetry/opentelemetry-java#7435

Closed

zeitlinger marked this pull request as draft June 25, 2025 07:07

zeitlinger force-pushed the spring-starter-declarative-config branch from bf6b7f8 to 9427fe6 Compare June 30, 2025 09:31

zeitlinger marked this pull request as ready for review June 30, 2025 10:42

zeitlinger marked this pull request as draft June 30, 2025 10:48

zeitlinger added this to Declarative Configuration: Java Jun 30, 2025

zeitlinger moved this to Blocked in Declarative Configuration: Java Jun 30, 2025

zeitlinger moved this from Blocked to In Progress in Declarative Configuration: Java Jul 4, 2025

zeitlinger removed this from Declarative Configuration: Java Jul 4, 2025

zeitlinger force-pushed the spring-starter-declarative-config branch from 482c0be to 5fcca3f Compare July 7, 2025 12:56

jaydeluca reviewed Nov 10, 2025

View reviewed changes

...io/opentelemetry/instrumentation/spring/autoconfigure/SpringDeclarativeConfigProperties.java Outdated Show resolved Hide resolved

...lemetry/instrumentation/spring/autoconfigure/internal/resources/DistroComponentProvider.java Outdated Show resolved Hide resolved

pr review

11089d0