opentelemetry-java
opentelemetry-java copied to clipboard
add Resource getter to ExtendedOpenTelemetrySdk
needed for https://github.com/open-telemetry/opentelemetry-java-contrib/pull/2296#discussion_r2515040501
Codecov Report
:x: Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 90.11%. Comparing base (c67641c) to head (04521dd).
| Files with missing lines | Patch % | Lines |
|---|---|---|
| .../extension/incubator/ExtendedOpenTelemetrySdk.java | 66.66% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #7832 +/- ##
============================================
- Coverage 90.11% 90.11% -0.01%
Complexity 7224 7224
============================================
Files 821 821
Lines 21809 21811 +2
Branches 2136 2136
============================================
+ Hits 19654 19655 +1
- Misses 1486 1487 +1
Partials 669 669
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
@jack-berg wdyt?
Oof I want this but..
- Even with breaking changes allowed in ExtendedOpenTelemetry, they still cause churn and we don't want to offer a capability and later have to withdraw it.
- In my mind ExtendedOpenTelemetry is the place we prototype new ideas, but the scope is still bound to concepts in the spec. To my knowledge the spec doesn't talk about this right now. Though I suspect that's changing with entities, and I want to make sure anything we do is aligned with whatever the current thinking is there. It doesn't have to perfectly embody the latest thinking, but it shouldn't be in tension with that.
@jsuereth what do you think?
Is it in line with entities to expose the resource in the extended otel instance?