-
Notifications
You must be signed in to change notification settings - Fork 1k
Fix spi file relocation clean #15523
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
Closed
Arunodoy18
wants to merge
3
commits into
open-telemetry:main
from
Arunodoy18:fix-spi-file-relocation-clean
Closed
Fix spi file relocation clean #15523
Arunodoy18
wants to merge
3
commits into
open-telemetry:main
from
Arunodoy18:fix-spi-file-relocation-clean
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When classes are relocated during shading (e.g., io.opentelemetry.instrumentation to io.opentelemetry.javaagent.shaded.instrumentation), the corresponding SPI files in META-INF/services/ were not being renamed to match the new class locations. This fix adds an eachFile block to the Shadow plugin configuration to rename SPI service files when shading is enabled. Now extensions can use the correct shaded class names in their SPI files. Fixes issue where InstrumenterCustomizerProvider and HttpClientUrlTemplateCustomizer SPI files needed to reference shaded class names but weren't being automatically renamed during the build process. Changes: - Added eachFile transformation to javaagent-shadowing.gradle.kts - Added eachFile transformation to muzzle-check.gradle.kts - Added test SPI file to demonstrate functionality Resolves issue open-telemetry#14825
…oconfigure The Kafka instrumentation autoconfiguration was missing the ability to configure messagingReceiveInstrumentationEnabled from the property 'otel.instrumentation.messaging.experimental.receive-telemetry.enabled'. This is required to control creation of separate spans in Spring Boot autoconfiguration for Kafka consumers. Changes: - Added setMessagingReceiveInstrumentationEnabled() call in KafkaInstrumentationAutoConfiguration - Uses the standard property 'otel.instrumentation.messaging.experimental.receive-telemetry.enabled' - Follows the same pattern as other messaging instrumentations (JMS, Pulsar, etc.) Fixes the missing configuration that was preventing proper control of Kafka consumer span creation in Spring Boot applications.
jaydeluca
reviewed
Dec 3, 2025
...ring/autoconfigure/internal/instrumentation/kafka/KafkaInstrumentationAutoConfiguration.java
Show resolved
Hide resolved
Context propagation was not working correctly for batch messages in RocketMQ 5.0+ because all messages in a batch were sharing the same receive span context instead of each message having its own context extracted from message properties. Changes: - Modified ReceiveSpanFinishingCallback to extract individual context for each message in the batch using MessageMapGetter to read trace headers - Each message now gets its own properly linked context for correct tracing - Re-enabled testRocketmqProduceAndBatchConsume test for latest dependencies This fixes the issue where batch message consumers would not properly propagate trace context from producers, breaking distributed tracing for RocketMQ batch message processing in versions 5.3.4+. Resolves the disabled test from open-telemetry#15512
Cirilla-zmh
reviewed
Dec 4, 2025
...pentelemetry/javaagent/instrumentation/rocketmqclient/v5_0/ReceiveSpanFinishingCallback.java
Show resolved
Hide resolved
laurit
reviewed
Dec 4, 2025
| relocate("application.java.util.logging", "java.util.logging") | ||
|
|
||
| // Rename SPI service files to match relocated class names | ||
| eachFile { |
Contributor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dis some AI com up with this? If so I'd suggest you to give up on #15513
This was referenced Dec 6, 2025
Member
|
Closing since this was a mix of concerns and new PR(s) have been opened since. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR addresses two important issues in OpenTelemetry Java Instrumentation:
Problem 1: SPI Service File Relocation
When classes are relocated during javaagent shading (e.g.,
io.opentelemetry.instrumentationtoio.opentelemetry.javaagent.shaded.instrumentation), the corresponding SPI files inMETA-INF/services/were not being renamed to match the new class locations.This caused extensions to require shaded class names instead of original names when using
InstrumenterCustomizerProviderandHttpClientUrlTemplateCustomizer.Problem 2: Kafka Messaging Configuration Gap
The Kafka instrumentation autoconfiguration was missing the ability to configure
messagingReceiveInstrumentationEnabledfrom the propertyotel.instrumentation.messaging.experimental.receive-telemetry.enabled, making it impossible to control creation of separate spans in Spring Boot Kafka consumers.Solutions
SPI Fix
eachFiletransformation to Shadow plugin configuration in bothjavaagent-shadowing.gradle.ktsandmuzzle-check.gradle.ktsKafka Configuration Fix
setMessagingReceiveInstrumentationEnabled()call inKafkaInstrumentationAutoConfigurationotel.instrumentation.messaging.experimental.receive-telemetry.enabledTesting
Files Changed
conventions/src/main/kotlin/io.opentelemetry.instrumentation.javaagent-shadowing.gradle.ktsgradle-plugins/src/main/kotlin/io.opentelemetry.instrumentation.muzzle-check.gradle.ktsjavaagent-tooling/src/main/resources/META-INF/services/io.opentelemetry.instrumentation.api.incubator.semconv.http.HttpClientUrlTemplateCustomizerinstrumentation/spring/spring-boot-autoconfigure/src/main/java/io/opentelemetry/instrumentation/spring/autoconfigure/internal/instrumentation/kafka/KafkaInstrumentationAutoConfiguration.java