@trask @mateuszrzeszutek hello, what do you think about
SingleThreadedSpringWebfluxTest, the test contains dependencies on new
reactor netty classes in testLatestDeps case. I tried use reflection for
rewriting the test to java but it was not trivial and I not reach the
result
---------
Co-authored-by: Lauri Tulmin <ltulmin@splunk.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>
Another part of #932
In this PR I changed all the library instrumentation packages -- these
are breaking changes, so I figured the earlier we do this the less
painful it'll be to the users. I know that at least some of them are
actively used, so we'll need to spell this out in the release notes.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
We are seeing examples where Spring Scheduling INTERNAL spans are
created inside of an existing parent span, which creates unnecessary
noise.
And these spans don't necessary make sense as these are not "background
jobs" (since they occur inside of an existing span).
(see for example
https://github.com/microsoft/ApplicationInsights-Java/issues/2870)
This PR changes Spring Scheduling instrumentation to only instrumenting
repeating jobs, not one-time scheduled jobs (which corresponds to
ScheduledExecutorService behavior where context is not propagated to
runnable)
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
…n-api-semconv
We're already doing that for `SpanNameExtractor`, `OperationMetrics`,
`ContextCustomizer`, etc., so I figured we should do the same for
`AttributesExtractor` implementation. Also, none of the implementations
have any additional public surface - aside from the builder/factory
method users can just simply use the interface everywhere.
This is another follow-up from #7616. This makes the test options class
immutable and uses `@AutoValue` and `@AutoValue.Builder`. As a result, a
bunch of the configuration/setup code for these said options now flings
around a builder instance. This isn't great, but I think it's an
incremental improvement that can be seen in the `@BeforeAll
AbstractHttpClientTest.setupOptions()` method, where the immutable
options are (finally) instantiated.
I decided splitting changes on different PRs due to there are a lot of
lines of code in tests here and it should simplify review process.
Another option is I can add additional commit to this PR with conversion
of other groovy files.
As part of discussions #7616, the idea of trying to do a more piecemeal
approach came up. A reasonable ask.
This is the first step in refactoring the http client tests. It factors
out the `HttpClientResult` inner class of the `AbstractHttpClientTest`
so that this can be reused by new test framework later. It also factors
the relevant abstract methods in the abstract class to a new type
adapter, which will also be reused.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
This PR includes updates to the SQLSanitizer, DbClientSpanNameExtractor
and SqlStatementInfo to name spans according to procedure name for CALL
statements. The updates to the naming logic are in the SqlSanitizer and
table has been renamed to identifier as using the table variable for the
procedure name would not be idiomatic. SqlStatementInfo has been updated
so that the db.sql.table attribute is not included for procedures.