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.
There were so many changes in the tests that extracting a base class
wouldn't really improve the readability; so I just reimplemented them in
Java.
The instrumentation itself is pretty much a copy-paste of the `jms-1.1`
instrumentation, with `s/javax/jakarta/` applied.
Related to #7220
Unfortunately it doesn't fix the aforementioned issue; while the CL used
is no longer the agent classloader, gauge collection still throws that
error.
Still, I think this is a good change that removes one source of agent's
CL leaking into application runtime.
Working PR to capture all the changes required to update to otel java
1.19.0. The new log API force allows
`:instrumentation-appender-api-internal` and
`:instrumentation-appender-sdk-internal`, but necessitates a decent
amount of refactoring as a result.
The PR points at the `1.19.0-SNAPSHOT`, which I'll update upon
publication.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
* Move concurrent instrumentation utils out from javaagent-instrumentation-api
* Move AgentLogEmitterProvider, InstrumentedTaskClasses and OpenTelemetrySdkAccess out of javaagent-instrumentation-api
* during install, hook up the log emitter provider for instrumentation to use.
* spotless
* Fix tests
* Default instrumentation name to ROOT when logger name null/empty
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
* rename artifacts and packages
* Library users shouldn't need to use internal
* Update docs
* Rename in order to simplify HelperClassPredicate
* Spotless
* Move AgentLogEmitterProvider to javaagent-instrumentation-api
* Test captured HTTP headers - HTTP server tests, part 1
* Upgrade undertow in resteasy tests (Undertow 1.0 had a bug where it thrown NPE on getHeaders())