@tylerbenson noted that the idea of assigning each matcher a index that
is used to cache the matching status in bit set is not obvious. Here's
an attempt to improve the comments.
See
https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/7698
This is an attempt to reduce memory usage for
`ClassLoaderHasClassesNamedMatcher`. Instead of having each matcher keep
a `Map<ClassLoader, Boolean>` we can have one `Map<ClassLoader, BitSet>`
where each matcher uses one bit in the `BitSet`. Alternatively
`Map<ClassLoader, Set<ClassLoaderHasClassesNamedMatcher>>` where set
contains matchers that match for given class loader would also work well
because these matchers usually don't match so we can expect to have only
a few elements in the set.
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.
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>
otelbot[bot]
SylvainJuge
Lauri Tulmin
jack-berg
Gregor Zeitlinger
Jonas Kunz
dingjiefei
jason plumb
Helen
Mateusz Rzeszutek
Phil Clay
cleverchuk
Matthieu MOREL
jackshirazi
dependabot[bot]
Ago Allikmaa
adamleantech
Trask Stalnaker