This allows custom distributions of the agent to register
`HttpServerResponseCustomizer` implementations. When a supported HTTP
server instrumentation starts processing a response, the `onStart`
method of all registered implementations will be invoked with the
`Context` of the SERVER span, an instrumentation-specific response
object and `HttpServerResponseMutator` instance that allows appending
headers to that response.
The intent of this is to allow custom distributions to set a header
containing span context information, such as the trace and span IDs. As
such, the initial implementation only allows appending response headers
and nothing else.
The `HttpServerResponseCustomizer` and related classes are currently in
a subpackage of the `io.opentelemetry.javaagent.bootstrap` package in
`javaagent-extension-api`. This makes them get loaded in the bootstrap
classloader, thus directly accessible from instrumentations. I am not
aware if there is an elegant way to put it in the agent classloader
instead, yet have the same instance accessible from both
`AgentInstaller` and instrumentations.
This also includes Tomcat-specific implementation in order to be able to
demonstrate that it works, and add automated testing of this to
HttpServerTest including one implementation.
- use standard messaging span name
- replace `message.type` with experimental attribute
`messaging.pulsar.message.type`, `message.type` is from rpc semantic
conventions
- replace `net.sock.peer.addr` that was filled with broker url with
`net.peer.name` and `net.peer.port`
The intention here is to allow users of the java agent to set a VM flag
in order to be able to add values in the current Baggage context to MDC
for logback. It seemed unwise to turn this on by default - if the
application is configured to print all MDC contents (as it often the
case with JSON output) then baggage would be logged out by default which
may either bloat the logs or result in sensitive data being exposed
unitentionally.
Addresses #1391 and #6708
Note that this is my first contribution to this repo, I've done my best
to follow the existing approaches to things like testing but would
appreciate any feedback.
---------
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
It follows the
[issue](https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/6395#issue-1323561263)
I opened some days ago.
The `executeReactive` method use the same processor used by
`executeAsync` (see
[here](65d2c19c40/core/src/main/java/com/datastax/dse/driver/internal/core/cql/reactive/CqlRequestReactiveProcessor.java (L53)))
and wrap the callback in the `DefaultReactiveResultSet` publisher.
Here I'm simply overriding the `executeReactive` method doing the same
thing: call the already instrumented `executeAsync` method and wrapping
the callback using the `DefaultReactiveResultSet` publisher.
~~I did an upgrade of the `java-driver-core` library to have
`TracingCqlSession.java` extending the `ReactiveSession`. I have to
probably rename the `cassandra-4.0` module in `cassandra-4.14` but I'll
let you confirm this.~~ -> Cassandra-4.4 is enough.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7436
* Created new Module `spring-webflux-5.3` which contains only
server-side library instrumentation
* Minimum supported version is 5.3 because there are various problems in
older versions of reactor and webflux that prevent a few of the tests
from passing.
* Moved existing `spring-webflux-5.0` (webclient instrumentation) into a
common `spring-webflux` folder next to the 5.3 (server) instrumentation.
Moved the README to the parent folder so the docs are cohesive between
client/server instrumentation.
* Implemented `WebFilter` which instruments the server-side
* Depends on the `reactor-3.1` instrumentation to pass the context
around. Registers the react hook when it creates the `WebFilter`
* Tests using the standard HTTP server test suite
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Hopefully avoids exceptions like
`org.apache.rocketmq.shaded.io.grpc.StatusRuntimeException:
DEADLINE_EXCEEDED: deadline exceeded after...` in rocketmq 5 test setup.
Resolves#7894
Replace `MethodHandle` with older `java.lang.reflect.Field`, which is
supported on older Java versions.
Also enables animal sniffer for the RxJava2 instrumentation to prevent
regression.
---------
Co-authored-by: opentelemetrybot <107717825+opentelemetrybot@users.noreply.github.com>
Lauri Tulmin