Mateusz Rzeszutek
|
cde2e70148
|
Implement new stable server semantic conventions (#8663)
|
2023-06-13 11:07:59 +02:00 |
|
Mateusz Rzeszutek
|
506ccb6b7d
|
Implement new stable network semantic conventions (#8616)
|
2023-06-12 16:51:47 +02:00 |
|
Mateusz Rzeszutek
|
5b03ae655f
|
Implement new stable HTTP semantic conventions (#8632)
|
2023-06-08 20:02:45 -07:00 |
|
Mateusz Rzeszutek
|
8ee63d4441
|
Implement new stable URL semantic conventions (#8491)
|
2023-06-05 15:22:22 +00:00 |
|
Mateusz Rzeszutek
|
e3944a53a5
|
Make net.transport an optional attribute (#8279)
|
2023-04-20 08:14:03 -07:00 |
|
Mateusz Rzeszutek
|
f501569106
|
Switch from http.flavor to net.protocol.* in HTTP client instrumentat… (#8131)
|
2023-04-07 13:39:42 +02:00 |
Lauri Tulmin
|
08236a710f
|
Add library instrumentation for java http client (#8138)
Resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/8069
The javaagent instrumentation also supports propagating context into
[BodyHandler](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpResponse.BodyHandler.html)
implemented in
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/java-http-client/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/httpclient/BodyHandlerWrapper.java
I think the initial idea behind it was that this allowed propagating
context into callbacks. Because this didn't work for
`connectionErrorUnopenedPortWithCallback` test later we also added
wrapping completable future to take care of propagating context into
callbacks. Should I also implement context propagation for `BodyHandler`
in library instrumentation or should I just delete it? I guess it could
come handy if someone builds a custom `BodyHandler` and wants to emit
spans from there, though this doesn't feel too likely. I'd like deleting
it more.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
|
2023-04-03 13:08:29 -07:00 |