Skip to content

Instrument extended open telemetry #15178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
trask merged 20 commits into from
Nov 19, 2025
Merged

Instrument extended open telemetry #15178

trask merged 20 commits into from
Nov 19, 2025
+403 −16

Conversation

@zeitlinger
Copy link
Member

@zeitlinger zeitlinger commented Oct 29, 2025 •
edited
Loading

Fixes #14191

@zeitlinger zeitlinger requested a review from a team as a code owner October 29, 2025 16:48
@zeitlinger zeitlinger self-assigned this Oct 29, 2025
@zeitlinger zeitlinger mentioned this pull request Oct 29, 2025
Closed
@zeitlinger
Copy link
Member Author

zeitlinger commented Oct 29, 2025

I'm getting

class io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 cannot be cast to class io.opentelemetry.api.incubator.ExtendedOpenTelemetry (io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 and io.opentelemetry.api.incubator.ExtendedOpenTelemetry are in unnamed module of loader 'app')
java.lang.ClassCastException: class io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 cannot be cast to class io.opentelemetry.api.incubator.ExtendedOpenTelemetry (io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 and io.opentelemetry.api.incubator.ExtendedOpenTelemetry are in unnamed module of loader 'app')

@laurit can you give me a hint?

@laurit
Copy link
Contributor

laurit commented Oct 30, 2025

I'm getting

class io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 cannot be cast to class io.opentelemetry.api.incubator.ExtendedOpenTelemetry (io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 and io.opentelemetry.api.incubator.ExtendedOpenTelemetry are in unnamed module of loader 'app')
java.lang.ClassCastException: class io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 cannot be cast to class io.opentelemetry.api.incubator.ExtendedOpenTelemetry (io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_27.ApplicationOpenTelemetry127 and io.opentelemetry.api.incubator.ExtendedOpenTelemetry are in unnamed module of loader 'app')

@laurit can you give me a hint?

I thin you forgot to actually use the ApplicationOpenTelemetry155Incubator that you added. Have a look at

opentelemetry-java-instrumentation/instrumentation/opentelemetry-api/opentelemetry-api-1.0/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/opentelemetryapi/ApplicationOpenTelemetry.java

Line 22 in 39137d1

OpenTelemetry instance = getOpenTelemetry127();

@zeitlinger
Copy link
Member Author

zeitlinger commented Oct 30, 2025

Thanks @laurit - can you check if this PR together with the SDK PR make sense (see ticket description)?

@zeitlinger zeitlinger marked this pull request as draft October 30, 2025 12:29
@zeitlinger zeitlinger mentioned this pull request Nov 3, 2025
Open
@zeitlinger zeitlinger force-pushed the instrument-extended-open-telemetry branch from 751e093 to e7a46a5 Compare November 8, 2025 10:55
@zeitlinger zeitlinger marked this pull request as ready for review November 8, 2025 11:30
@zeitlinger
Copy link
Member Author

zeitlinger commented Nov 8, 2025

opentelemetry-api-1.47 has this error - not sure what the problem is

    [otel.javaagent 2025-11-08 12:09:21:713 +0100] [Test worker] WARN io.opentelemetry.javaagent.tooling.instrumentation.MuzzleMatcher - Instrumentation skipped, mismatched references were found: opentelemetry-api [class io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_56.incubator.OpenTelemetryApiIncubatorInstrumentationModule] on jdk.internal.loader.ClassLoaders$AppClassLoader@76ed5528
    [otel.javaagent 2025-11-08 12:09:21:729 +0100] [Test worker] WARN io.opentelemetry.javaagent.tooling.instrumentation.MuzzleMatcher - -- io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_56.incubator.ApplicationOpenTelemetry156Incubator:39 Missing class io.opentelemetry.api.incubator.config.ConfigProvider
    [otel.javaagent 2025-11-08 12:09:21:729 +0100] [Test worker] WARN io.opentelemetry.javaagent.tooling.instrumentation.MuzzleMatcher - -- io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_56.incubator.ApplicationOpenTelemetry156Incubator:0 Missing class io.opentelemetry.api.incubator.ExtendedOpenTelemetry
    [otel.javaagent 2025-11-08 12:09:21:729 +0100] [Test worker] WARN io.opentelemetry.javaagent.tooling.instrumentation.MuzzleMatcher - -- io.opentelemetry.javaagent.instrumentation.opentelemetryapi.v1_56.incubator.config.ApplicationDeclarativeConfigProperties156Incubator:0 Missing class io.opentelemetry.api.incubator.config.DeclarativeConfigProperties

@zeitlinger
Copy link
Member Author

zeitlinger commented Nov 8, 2025

@laurit can you help with the error?

@zeitlinger
Copy link
Member Author

zeitlinger commented Nov 9, 2025

@laurit can you help with the error?

I think I figured it out 😄

laurit
laurit reviewed Nov 11, 2025
View reviewed changes
...y/javaagent/instrumentation/opentelemetryapi/v1_56/common/ApplicationComponentLoader156.java Outdated

@Override
public <T> Iterable<T> load(Class<T> type) {
return componentLoader.load(type);
Copy link
Contributor

@laurit laurit Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this really work? I'd imagine that it will return agent classes that the application code can not process. Without thinking about it too much I'm not even sure it is possible to implement this.

Copy link
Member Author

@zeitlinger zeitlinger Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right - I can't think of a use case where this is needed after the SDK has been set up. Maybe just throw a helpful exception?

Copy link
Contributor

@laurit laurit Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

either exception or an empty iterable, idk which would be preferable here. cc @trask

Copy link
Member

@trask trask Nov 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea of exposing component loader in the configuration API is for instrumentations to use it to load misc components they might need (@jack-berg?)

in which case I think we would want to load from the user class loader here if possible

Copy link
Member

@jack-berg jack-berg Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea of exposing component loader in the configuration API is for instrumentations to use it to load misc components they might need (@jack-berg?)

  • The agent and spring boot starter use their own implementation of component loader for classloader reasons.
  • This means that everything loaded via SPI during SDK intialization needs to use whatever component loader is configured
  • All the SDK extension points are modeled as implementations of ComponentProvider, and instantiated via ComponentProvider#create(DeclarativeConfigProperties). This includes things like the OTLP exporters which load compressors and senders via SPI.
  • So we're able to pass the agent / spring boot starter component loader down to the OTLP exporters via DeclarativeConfigProperties#getComponentLoader().
  • Any ComponentProvider implementation that loads via SPI should similarly use DeclarativeConfigProperties#getComponentLoader().

Copy link
Member Author

@zeitlinger zeitlinger Nov 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #15406 to discuss

@zeitlinger zeitlinger force-pushed the instrument-extended-open-telemetry branch from e6e78cc to b673cb8 Compare November 11, 2025 13:50
@laurit laurit added this to the v2.22.0 milestone Nov 12, 2025
@trask
Copy link
Member

trask commented Nov 19, 2025

merging, but please open an issue to track what to do with #15178 (comment)

@trask trask merged commit 5e38413 into open-telemetry:main Nov 19, 2025
89 checks passed
@zeitlinger zeitlinger deleted the instrument-extended-open-telemetry branch November 20, 2025 11:24
@zeitlinger zeitlinger mentioned this pull request Nov 20, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@trask trask trask left review comments

@jack-berg jack-berg jack-berg left review comments

@laurit laurit laurit approved these changes

Assignees

@zeitlinger zeitlinger

Labels

None yet

Projects

None yet

Milestone

v2.22.0

Development

Successfully merging this pull request may close these issues.

Add instrumentation for ExtendedOpenTelemetry

4 participants

@zeitlinger @laurit @trask @jack-berg