Bumps [spotless-plugin-gradle](https://github.com/diffplug/spotless)
from 6.12.0 to 6.12.1.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="718a504c12"><code>718a504</code></a>
Published gradle/6.12.1</li>
<li><a
href="c13acee213"><code>c13acee</code></a>
Published lib/2.31.1</li>
<li><a
href="552aabf876"><code>552aabf</code></a>
fix(deps): update dependency com.facebook:ktfmt to v0.42 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1421">#1421</a>)</li>
<li><a
href="4063e9f6d1"><code>4063e9f</code></a>
Add support for KtLint 0.48.0 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1432">#1432</a>
fixes <a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1430">#1430</a>)</li>
<li><a
href="062e835846"><code>062e835</code></a>
Bump changelogs.</li>
<li><a
href="8f7e00594d"><code>8f7e005</code></a>
spotlessApply</li>
<li><a
href="9a8ccae9ec"><code>9a8ccae</code></a>
Bump default ktfmt 0.41 -> 0.42</li>
<li><a
href="fb4277d2b1"><code>fb4277d</code></a>
Merge branch 'main-ktlint-0.48.0' into renovate/ver_ktfmt</li>
<li><a
href="b44d70d00a"><code>b44d70d</code></a>
Move changelog entries to the correct release.</li>
<li><a
href="b3d8e89002"><code>b3d8e89</code></a>
spotlessApply for 2023</li>
<li>Additional commits viewable in <a
href="https://github.com/diffplug/spotless/compare/gradle/6.12.0...gradle/6.12.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
In
https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/7447
injected resource is opened with class loader getResourceAsStream. This
works only in class loaders where getResourceAsStream delegates to
getResource. This is not the case with all class loaders, for example
tomcat class loader does not do this. Because of this we also need to
instrument class loader getResourceAsStream.
Changed them from standalone top-level attributes to move them under
`log4j.map_message.*` (e.g. similar to `log4j.context_data.*` and
others).
Also adds doc for log4j javaagent properties.
Also cleans up related tests.
Hopefully resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7124
Our kotlin coroutine instrumentation relies on a shaded copy of
`opentelemetry-extension-kotlin`. This doesn't work well when
application also uses `opentelemetry-extension-kotlin`, because the
shaded and unshaded copy store opentelemery context under different key.
This pr attempts to fix this by instrumenting
`opentelemetry-extension-kotlin` provided by the application so that it
would delegate to the one shaded inside the agent.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Will close#7216 after this is merged and that PR is rebased.
I tested and it does bring a few more scala versions into Intellij
without this, but scala is an odd case.
Fixes#7265
I took a look at the new Observation API, and I think that it still
makes sense to continue using the interceptors to implement this
instrumentation: they implement the OTel spec (which includes way more
attributes than the default observation convention implemented in
Spring), and cooperate with the Kafka client instrumentation and link
the receive and process spans together. And it's quite a simple change
in one of our interceptors, instead of rewriting everything.
(Draft because Spring Boot 3 hasn't released yet, and it is required to
run the tests. If we're not in a hurry this PR can wait a bit for that)
closes: #7028
For reasons explained in the linked issue, it might be handy to register
drivers directly against `OpenTelemetryDriver` rather than against
`DriverManager`. I decided to also go with static registry as drivers
are often instantiated connect pools (like Agroal) and it could be
difficult to use instance varibles. This PR adds additional `Driver`
collection where drivers can be registered. If driver is registered both
with `OpenTelemtryDriver` and `DriverManager`, drivers registered with
`OpenTelemetryDriver` are preferred.
I thought I was going to need this for #7293, but it seems like still a
good change, removes a bit of duplication across getHost and getPort,
and could be useful in the future if we want logic to grab both host and
port in a "single pass"
When a webflux filter is added which throws an exception, the
instrumentation does not currently capture the `http.status_code`.
The fix is to move `WebClientTracingFilter` from the first to the last
filter in the chain, which I think(?) is the general strategy we've
taken for other client instrumentation, e.g. so that if a filter makes
another http call it won't be suppressed.
I don't love the test coverage I added, so let me know if you have any
better suggestions?
EDIT: btw, I did archaeology to confirm that behavior (adding to the
beginning of the chain) has been in place since the webflux
instrumentation was added originally
6f472a62a0 (diff-493ad89b5bde807c90387aa2bb67eb10d3bcef6b6a388bd31e11796a6d01ac38R36)
Run callbacks added to the `CompletableFuture` returned from `sendAsync`
with the context that was used when `sendAsync` was called.
Add test for capturing message headers.