4bcb876c08
Bumps [mockito-core](https://github.com/mockito/mockito) from 4.11.0 to 5.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/mockito/mockito/releases">mockito-core's releases</a>.</em></p> <blockquote> <h2>v5.0.0</h2> <h1>Mockito 5: prepare for future JDK versions</h1> <p>For a while now, we have seen an increase in problems/incompatibilities with recent versions of the JDK due to our usage of JVM-internal API. Most notably, JDK 17 made some changes which are incompatible with the current subclass mockmaker. Therefore, to prepare for the future of JDK, we are making some core changes to ensure Mockito keeps on working.</p> <h2>Switch the default mockmaker to <code>mockito-inline</code></h2> <p>Back in Mockito 2.7.6, we published a new mockmaker based on the "inline bytecode" principle. This mockmaker creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery. As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior. While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes. For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.</p> <p>Massive thanks to community member <a href="https://github.com/reta"><code>@reta</code></a> who implemented this change.</p> <h3>When should I still be using the subclass mockmaker?</h3> <p>There are legitimate remaining use cases for the subclass mockmaker. For example, on the Graal VM's native image, the inline mockmaker will not work and the subclass mockmaker is the appropriate choice. Additionally, if you would like to avoid mocking final classes, using the subclass mockmaker is a possibibility. Note however that if you solely want to use the subclass mockmaker to avoid mocking final, you will run into the above mentioned issues on JDK 17+. We want to leave this choice up to our users, which is why we will keep on supporting the subclass mockmaker.</p> <p>If you want to use the subclass mockmaker instead, you can use the new <code>mockito-subclass</code> artifact (published <a href="https://search.maven.org/artifact/org.mockito/mockito-subclass">on Maven Central</a> along with all our other artifacts).</p> <h2>Update the minimum supported Java version to 11</h2> <p>Mockito 4 supports Java 8 and above. Similar to other open source projects, we are moving away from JDK 8 and to newer versions. The primary reason for moving away from JDK 8 is the increasing maintenance costs with keeping our own infrastructure working. Lately we have been running into more and more JDK 8 breakages. Additionally, while we want to support the newest JDK API's, our current solution to support both JDK 8 and newer versions causes <a href="https://github-redirect.dependabot.com/mockito/mockito/issues/2798">issues with the <code>SecurityManager</code></a>. Since we want Mockito to work on the newest version and more and more businesses adopting JDK 11, we have decided to make the switch as well.</p> <p>Massive thanks to community member <a href="https://github.com/reta"><code>@reta</code></a> who implemented this change.</p> <h3>What should I do if I still run JDK 8?</h3> <p>For JDK 8 and below, you can keep on using Mockito 4. This is similar to if you are using JDK 6, for which you can keep on using Mockito 2. The changes in Mockito 5 (for now) are primarily focused on the latest JDK versions, which means the API differences between Mockito 4 and 5 are minimal. However, over time this will most likely widen, so we do recommend adopting JDK 11 in the future.</p> <h2>New <code>type()</code> method on <code>ArgumentMatcher</code></h2> <p>One of our most used public API's for customizing Mockito is the <a href="https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/ArgumentMatcher.html"><code>ArgumentMatcher</code> interface</a>. The interface allows you to define a custom matcher, which you can pass into method arguments to provide more targeted matches. One major shortcoming of the <code>ArgumentMatcher</code> was the lack of varargs support.</p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|---|---|---|
| .. | ||
| agent | ||
| bootstrap | ||
| custom | ||
| gradle | ||
| instrumentation | ||
| smoke-tests | ||
| testing/agent-for-testing | ||
| README.md | ||
| build.gradle | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| settings.gradle | ||
README.md
Distro
Introduction
This repository serves as a collection of examples of extending functionality of OpenTelemetry Java instrumentation agent. It demonstrates how to repackage the aforementioned agent adding custom functionality. For every extension point provided by OpenTelemetry Java instrumentation, this repository contains an example of its usage.
General structure
This repository has four main submodules:
customcontains all custom functionality, SPI and other extensionsagentcontains the main repackaging functionality and, optionally, an entry point to the agent, if one wishes to customize thatinstrumentationcontains custom instrumentations added by vendorsmoke-testscontains simple tests to verify that resulting agent builds and applies correctly
Extensions examples
- DemoIdGenerator - custom
IdGenerator - DemoPropagator - custom
TextMapPropagator - DemoSampler - custom
Sampler - DemoSpanProcessor - custom
SpanProcessor - DemoSpanExporter - custom
SpanExporter - DemoServlet3InstrumentationModule - additional instrumentation
Instrumentation customisation
There are several options to override or customise instrumentation provided by the upstream agent. The following description follows one specific use-case:
Instrumentation X from Otel distribution creates span that I don't like and I want to change it in my vendor distro.
As an example, let us take some database client instrumentation that creates a span for database call and extracts data from db connection to provide attributes for that span.
I don't want this span at all
The easiest case. You can just pre-configure your distribution and disable given instrumentation.
I want to add/modify some attributes and their values does NOT depend on a specific db connection instance
E.g. you want to add some data from call stack as span attribute.
In this case just provide your custom SpanProcessor.
No need for touching instrumentation itself.
I want to add/modify some attributes and their values depend on a specific db connection instance
Write a new instrumentation which injects its own advice into the same method as the original one.
Use getOrder method to ensure it is run after the original instrumentation.
Now you can augment current span with new information.
See DemoServlet3Instrumentation.
I want to remove some attributes
Write custom exporter or use attribute filtering functionality in Collector.
I don't like Otel span at all. I want to significantly modify it and its lifecycle
Disable existing instrumentation.
Write a new one, which injects Advice into the same (or better) method as the original instrumentation.
Write your own Advice for this.
Use existing Tracer directly or extend it.
As you have your own Advice, you can control which Tracer you use.