Skip to content
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.

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

Add javaagent<->application context bridge for HttpRouteHolder #5838

Merged
merged 5 commits into from
Apr 22, 2022

Conversation

mateuszrzeszutek
Copy link
Member

Resolves #4319 -- there are no more context keys worth bridging in both instrumentation-api and instrumentation-api-semconv, this was the last useful one.

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

Resolves #4319

🎉

@mateuszrzeszutek mateuszrzeszutek force-pushed the context-bridge branch 2 times, most recently from 06d6fd8 to 02733bc Compare April 20, 2022 07:51
Comment on lines 29 to 30
// instrumentation-api specific instrumentation
new HttpRouteStateInstrumentation());
Copy link
Member Author

Choose a reason for hiding this comment

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

The solution to this issue turned out to be a bit more complex than expected -- I don't particularly like this, but I had to insert additional instrumentation-api instrumentation into the opentelemetry-api module, cause it uses the AgentContextWrapper. It doesn't add any muzzle dependencies though, so it should be completely neutral for applications that just use opentelemetry-api without instrumentation-api.

@trask
Copy link
Member

trask commented Apr 21, 2022

I haven't thought this through, so maybe missing something, but wondering if we can instead instrument HttpRouteHolder.get() and HttpRouteHolder.updateRoute(), we may not need a context key bridge for this, and then the instrumentation could live outside of the opentelemetry-api bridge

@trask
Copy link
Member

trask commented Apr 21, 2022

(a bit like #4786)

@mateuszrzeszutek
Copy link
Member Author

mateuszrzeszutek commented Apr 21, 2022

I haven't thought this through, so maybe missing something, but wondering if we can instead instrument HttpRouteHolder.get() and HttpRouteHolder.updateRoute(), we may not need a context key bridge for this, and then the instrumentation could live outside of the opentelemetry-api bridge

I thought that this would be a bit more difficult, since we'd have to bridge HttpRouteSource and HttpRouteBiGetter too, not just the Context. I left the context key bridging and extracted a separate instrumentation-api instrumentation; I also moved all the instrumentation-api context bridging tests there.

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

thx, I have a couple more thoughts about bridging, will explore in a follow-up 👍

@trask trask merged commit 2bb7873 into open-telemetry:main Apr 22, 2022
RashmiRam pushed a commit to RashmiRam/opentelemetry-auto-instr-java that referenced this pull request May 23, 2022
…telemetry#5838)

* Add javaagent<->application context bridge for HttpRouteHolder

* remove comments

* fix broken http.route bridge

* spotless

* Move to a separate module
@mateuszrzeszutek mateuszrzeszutek deleted the context-bridge branch November 18, 2022 10:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Context keys from instrumentation-api should be bridged
2 participants