Fix default service.name + simplify configuration using Otel AutoConfig SDK 1.10 ResourceProvider SPI improvements

[cyrille-leclerc]

Description:

Fix default service.name + simplify configuration using Otel AutoConfig SDK 1.10 ResourceProvider SPI improvements (enable specifying the classloader making it compatible with Maven Plexus)

Existing Issue(s):

• [Maven extension] cant set service name #183

Testing:

Introduced tests with OpenTelemetrySdkServiceTest

Documentation:

NONE

Outstanding items:

NONE

[cyrille-leclerc]

@kenfinnigan @trask sorry for the regression caused by the previous PR. I simplified the configuration code leveraging the AutoConfigure SDK 1.10 improvements and I introduced unit tests.

[trask]

I simplified the configuration code leveraging the AutoConfigure SDK 1.10 improvements and I introduced unit tests.

👍

[anuraaga]

Hmm - the code is a bit simpler but the previous version seems to be more robust since it was using the real RuntimeInformation. It's one of the reasons for adding the resource customizer hook, for these situations where some class is used that's not available statically

[cyrille-leclerc]

I'll iterate on this ASAP. I have to understand the best pattern to support default values provided by runtime components with overwrites by the environment variables

I see an interesting impedance question to integrate the Java ServiceLoader SPI with dependency injection frameworks like @inject. Do you see things the same way?

[anuraaga]

@cyrille-leclerc Yeah I don't think SPI works that well in the context of a system using dependency injection. So was hoping that the customizers on the builder will be able to solve those cases. Note that service.name is extremely special - it is one of few attributes automatically filled by the SDK, with the other ones having no use case for user customization.

https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/common/src/main/java/io/opentelemetry/sdk/resources/Resource.java#L48

So some ugly code handling it should be fine, the attribute itself is an ugly duckling, probably something like

if (oldResource.get(SERVICE_NAME).equals(Resource.getDefault().get(SERVICE_NAME)) { newResource.put(SERVICE_NAME, MAVEN_SERVICE_NAME); }

Long term if this is tricky in many cases, we could possibly consider adding a serviceName field to the SDK autoconfiguration builder that takes care of that logic, but for now we'd like to see how things go.

[cyrille-leclerc]

Sorry @anuraaga I missed your comment, your point makes sense. Many thanks!