Fix spi file relocation clean #15523
Open
+26
−7
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.
github-actions
bot
added
the
test native
jaydeluca
reviewed
Dec 3, 2025
| .getBoolean("otel.instrumentation.kafka.experimental-span-attributes", false)) | ||
| config.getBoolean("otel.instrumentation.kafka.experimental-span-attributes", false)) | ||
| .setMessagingReceiveInstrumentationEnabled( | ||
| config.getBoolean("otel.instrumentation.messaging.experimental.receive-telemetry.enabled", false)) |
Member
There was a problem hiding this comment.
you should open separate PRs for these changes
Author
There was a problem hiding this comment.
Yeah i will make sure it happens next time.
Contributor
There was a problem hiding this comment.
If your intent is to get something merged then remove everything else from this PR or move just this part to a separate PR. Also add this configuration option to https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/spring/spring-boot-autoconfigure/src/main/resources/META-INF/additional-spring-configuration-metadata.json
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
| // Extract context from individual message properties (trace headers) | ||
| Context messageContext = RocketMqSingletons.propagators() | ||
| .getTextMapPropagator() | ||
| .extract(context, messageView, MessageMapGetter.INSTANCE); |
Member
There was a problem hiding this comment.
I don't think this would fix #15526. rocketmq-client-5.0 module is the instrumentation for org.apache.rocketmq:rocketmq-client-java while rocketmq-client-4.8 module is for org.apache.rocketmq:rocketmq-client. So you need to focus on the rocketmq-client-4.8 module to resolve this issue.
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.
Dis some AI com up with this? If so I'd suggest you to give up on #15513
This was referenced Dec 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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