Add experimental SdkResourceProvider implementation by jack-berg · Pull Request #8865 · open-telemetry/opentelemetry-java

jack-berg · 2026-09-25T21:47:14Z

Introduce SdkResourceProvider, representing the ResourceProvider spec concept added in opentelemetry-specification#5057.

Shape:

Add new SdkResourceProvider, SdkResourceProviderBuilder.
- Composed of one or more ResourceDetector (new internal concept). A resource detector is a single source of a resource.
- The merged resource from the detectors is used to serve the key operation: getResource()
- SdkResourceProviderBuilder has methods for adding static resources, and in the future can have methods for adding resources who's entity's descriptive attributes are subject to change
SdkTracerProviderBuilder, SdkMeterProviderBuilder, SdkLoggerProviderBuilder all have new setResourceProvider(..) methods, which is mutually exclusive with existing setResource(..) / addResource(..) methods
SdkTracerProvider, SdkMeterProvider, SdkLoggerProvider all have new getResourceProvider method. This is always available, whether a caller invoked setResourceProvider(..) or setResource(..) / addResource(..). If the later were called, a SdkResourceProvider is derived from the static resource
ExtendedOpenTelemetrySdk has a new getSdkResourceProvider() method for accessing the resource provider. The value is derived at construction time by looking at getResourceProvider() of SdkTracerProvider, SdkMeterProvider, SdkLoggerProvider. If they all agree, you get a result. If they disagree, we throw an exception.
Inside of SdkLoggerProvider, SdkMeterProvider, SdkTracerProvder are "shared state" objects like LoggerSharedState. These are used to resolve the resource attached to span / metric / logrecord records. These have been updated to attach the result of the resolved SdkResourceProvider.

In followups, we need to:

Update autoconfigure / declarative config to attach SdkResourceProviders to SdkMeterProvider, SdkLoggerProvider, SdkTracerProvider instead of a resource
Add functionality to be able to re-compute the resource without destroying hot path performance. Currently, getResource() is called on the hotpath for span and log creation. Need to develop a caching / TTL mechanism to occasionally recompute the resource, or shift it off the hot path entirely into some sort of background task.
Update autoconfigure to always return an ExtendedOpenTelemetrySdk instance, such that SdkResourceProvider is consistently available whether autoconfigure or declarative config is used

This functionality segues nicely with @jsuereth's #8464: each entity aware resource detector becomes one of these new ResourceDetector instances and are added to SdkResourceProvider. The work josh has done to update the Resource#merge behavior to merge entities is brought over here for free. And we have a natural starting point for refreshing / recomputing resource / entities.

@open-telemetry/java-approvers heads up on this - as well as embodying a new spec concept and helping the entities story, this is the key to unblocking the two additional use cases we identified where consumers of the SDK need to access the resolved resource: opamp and process context sharing.

opentelemetry-pr-dashboard · 2026-09-25T21:48:34Z

Pull request dashboard status

Waiting on the author · refreshed 2026-10-17 04:16 UTC

Respond to 9 review items (e.g. link a commit, explain why not, ask a follow-up):

Inline threads: 1, 2, 3, 4, 5, 6, 7, 8, 9

Status above doesn't look right?

Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
Should this be with reviewers? Comment /dashboard route:reviewers to route it to them.
Anything wrong — including the routing? Report it with what you expected; it helps us improve the dashboard.

jack-berg · 2026-09-25T21:50:53Z

+   * iteration - all detectors are cached at construction. TTL-based cache invalidation using this
+   * flag is planned for a future iteration.
+   */
+  boolean shouldReinvoke();


Since we're not doing anything with this today, we could punt on this. But the whole idea is sort of contrived and pointless without it. There's no need for a dedicated ResourceDetector / ResourceProvider framework when Resource / ResourceBuilder already allow you to iteratively construct a resource.

But Resource/ResourceBuilder break down with entity requirements. The design in this PR tries to accomplish the core goal of making SDK resource information accessible to things like opamp, process context sharing, etc with a forward looking api.

Seems like a bit of future-proofing, which I think is usually discouraged in public APIs since it's so easily added later when it's needed. I'd leave it out, but don't feel strongly about it.

codecov · 2026-09-25T22:04:30Z

Codecov Report

❌ Patch coverage is 89.60000% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.65%. Comparing base (63150e0) to head (79fd5a1).

Files with missing lines	Patch %	Lines
...metry/sdk/logs/internal/SdkLoggerProviderUtil.java	69.23%	4 Missing ⚠️
...try/sdk/metrics/internal/SdkMeterProviderUtil.java	69.23%	4 Missing ⚠️
...etry/sdk/trace/internal/SdkTracerProviderUtil.java	69.23%	4 Missing ⚠️
...lemetry/sdk/internal/ExtendedOpenTelemetrySdk.java	93.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8865      +/-   ##
============================================
+ Coverage     90.61%   90.65%   +0.03%     
- Complexity    10882    10930      +48     
============================================
  Files          1015     1018       +3     
  Lines         29731    29849     +118     
  Branches       3876     3882       +6     
============================================
+ Hits          26942    27060     +118     
  Misses         1872     1872              
  Partials        917      917

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

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jsuereth · 2026-10-08T18:57:35Z

+import io.opentelemetry.sdk.resources.Resource;
+import javax.annotation.Nullable;
+
+final class ConstantResourceDetector implements ResourceDetector {


oooh - interesting. Do you think this needs to be one of the 'out of the box' specified detectors?

Not sure. I did this because I had to. I think it makes sense to build SdkResourceProvider around the idea that resource attributes may change at runtime via entity descriptive attributes, but in practice all resources today (and most in the future) are statically evaluated at config time. So having syntactic sugar to reflect the common case is a must.

BTW I decided (b82c1bd) that the whole notion of a ResourceDetector should be hidden from users. Given that we already have ResourceProvider and ComponentProvider (i.e the declarative config version), having yet another interface for providing resources is too confusing a UX.

Instead, we can just have methods in SdkResourceProviderBuilder which reflect the different styles of resources that might need to be associated with a provider:

public final class SdkResourceProviderBuilder { public SdkResourceProviderBuilder addConstantResource(Resource resource); public SdkResourceProviderBuilder addConstantResource(Resource resource, @Nullable String name); public SdkResourceProvider build(); // Proposed future expansion public SdkResourceProviderBuilder addDetector(Supplier<Resource> resourceSupplier, Duration refreshInterval); public SdkResourceProviderBuilder addDetector(Supplier<Resource> resourceSupplier, Duration refreshInterval, @Nullable String name); }

jsuereth

Awesome! This looks a lot like an earlier prototype of Entities I had, but a good bit cleaner.

…ource to SdkResourceProviderBuilder

…y-java into sdk-resource-provider

zeitlinger · 2026-10-15T16:33:15Z

+        && tracerResource.equals(loggerRp.getResource())) {
+      return tracerRp;
+    }
+    return null;


should this log a warning?

it throws an exception above when getSdkResourceProvider() is called. That should do it huh?

breedx-splk · 2026-10-15T20:55:56Z

        openTelemetrySdk.getPropagators());
    this.openTelemetrySdk = openTelemetrySdk;
    this.configProvider = new ObfuscatedConfigProvider(configProvider);
+    this.resourceProvider = resolveSdkResourceProvider(openTelemetrySdk);


Nit: This feels like too much "work in the constructor". Prefer moving the resolve call to the create() method and passing in the true dependency (ResourceProvider).

breedx-splk · 2026-10-15T21:40:21Z

+
+  SdkResourceProvider(List<ResourceDetector> detectors) {
+    this.detectors = Collections.unmodifiableList(new ArrayList<>(detectors));
+    this.cachedResource = merge(this.detectors);


Because the detectors might be doing actual, real work (like going out and discovering or finding stuff)....I don't love the idea of ~~escaping the constructor~~ doing work in the constructor like this, as I think it can lead to a weird class of problem that's hard to troubleshoot, and object construction having side effects is usually unexpected behavior.

Prefer a factory method and passing in the true dependency: Resource.

Ok maybe escaping the constructor usually means leaking this outside the class...so that's not really happening here, but it still makes me twitchy because object construction could have side effects.

Not sure what you mean by escaping the constructor.

This looks odd right now because all detectors are static. But in the future, we want to add detectors that needs to be periodically refreshed.

breedx-splk · 2026-10-15T21:51:21Z

+    if (resourceProvider != null && resourceExplicitlySet) {
+      throw new IllegalStateException(
+          "setSdkResourceProvider is mutually exclusive with setResource / addResource.");
+    }


I anticipate this being a little tricky to get thoroughly complete. Would moving this to the setters (and changing the wording) help us better understand the ordering when it happens (eg. was the resource set before the provider, or the other way around?)?

Isn't the intention here to make sure that only one of setResource or setSdkResourceProvider was used?
I think its independent of order in which these methods were invoked, right ?

breedx-splk · 2026-10-15T21:58:49Z

+    if (resourceProvider != null && resourceExplicitlySet) {
+      throw new IllegalStateException(
+          "setSdkResourceProvider is mutually exclusive with setResource / addResource.");
+    }


Same comment/thought as above -- if we moved this check into the setters, can we both drop the explicit boolean member and just throw on set with better visibility into the ordering problem?

breedx-splk · 2026-10-15T21:59:50Z

+    if (resourceProvider != null && resourceExplicitlySet) {
+      throw new IllegalStateException(
+          "setSdkResourceProvider is mutually exclusive with setResource / addResource.");
+    }


same comment as the other two builders

breedx-splk

Looking good here. There's already some approvals, so I'm just holding off to see if any of my suggestions merit follow-ups, but this is mostly solid to me!

psx95 · 2026-10-16T21:47:12Z

+            .addConstantResource(RESOURCE_B)
+            .build();
+
+    assertThat(provider.getResource()).isEqualTo(RESOURCE_A.merge(RESOURCE_B));


nit: I think we need an overlapping attribute to actually test the merge order.

psx95 · 2026-10-16T22:49:03Z

+    if (resourceProvider != null && resourceExplicitlySet) {
+      throw new IllegalStateException(
+          "setSdkResourceProvider is mutually exclusive with setResource / addResource.");
+    }


Isn't the intention here to make sure that only one of setResource or setSdkResourceProvider was used?
I think its independent of order in which these methods were invoked, right ?

psx95 · 2026-10-16T23:13:05Z

+  private static Resource merge(List<ResourceDetector> detectors) {
+    Resource resource = Resource.empty();
+    for (ResourceDetector detector : detectors) {
+      resource = resource.merge(detector.getResource());


Just wanted confirm the pairwise merge functionality here. The documentation of the Resource.merge dictates that if the two resources being merged have non-null schema types, then the resulting merged resource has no schema URL

So when merging 3 or more resources with all different, non-null schema types then the resulting merged resource would have the schema type of the last resource.

Is this the expected behavior?

psx95 · 2026-10-16T23:23:45Z

+   * Returns the name of this detector, or {@code null} if unnamed. Names are informational (e.g.
+   * for logging / debugging) and are not required to be unique.


I got confused by this Javadoc because the spec on Resource Detector Name suggests that it should be unique and this Javadoc explicitly states otherwise.

Looking closely, this is probably not the responsible component for how the resource detectors are looked up. I'm thinking adding some clarification to the Javadoc around what this method is actually intended to be used for would be good.

Add experimental SdkResourceProvider implementation

e4d4d2f

jack-berg requested a review from a team as a code owner September 25, 2026 21:47

opentelemetry-pr-dashboard Bot mentioned this pull request Sep 25, 2026

Pull Request Dashboard #8439

Open

jack-berg commented Sep 25, 2026

View reviewed changes

jack-berg commented Sep 29, 2026

View reviewed changes

Comment thread sdk/common/src/main/java/io/opentelemetry/sdk/resources/internal/ResourceDetector.java Outdated

jsuereth reviewed Oct 8, 2026

View reviewed changes

jsuereth approved these changes Oct 8, 2026

View reviewed changes

jack-berg added 2 commits October 9, 2026 09:27

Make ResourceDetector package private, add method to add constant res…

b82c1bd

…ource to SdkResourceProviderBuilder

Merge branch 'main' of https://github.com/open-telemetry/opentelemetr…

79fd5a1

…y-java into sdk-resource-provider

zeitlinger approved these changes Oct 15, 2026

View reviewed changes

breedx-splk reviewed Oct 15, 2026

View reviewed changes

Comment thread sdk/all/src/main/java/io/opentelemetry/sdk/internal/ExtendedOpenTelemetrySdk.java

breedx-splk reviewed Oct 15, 2026

View reviewed changes

psx95 reviewed Oct 16, 2026

View reviewed changes

		* Returns the name of this detector, or {@code null} if unnamed. Names are informational (e.g.
		* for logging / debugging) and are not required to be unique.

Conversation

jack-berg commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

opentelemetry-pr-dashboard Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull request dashboard status

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsuereth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

breedx-splk Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

breedx-splk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

psx95 Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jack-berg commented Sep 25, 2026 •

edited

Loading

opentelemetry-pr-dashboard Bot commented Sep 25, 2026 •

edited

Loading

codecov Bot commented Sep 25, 2026 •

edited

Loading

breedx-splk Oct 15, 2026 •

edited

Loading

psx95 Oct 16, 2026 •

edited

Loading