Release v1.2.0

[trask]

Note that all artifacts other than io.opentelemetry.javaagent:opentelemetry-javaagent have the -alpha suffix attached to their version number, reflecting that they are still alpha quality and will continue to have breaking changes. Please see the VERSIONING.md for more details.

🌟 New javaagent instrumentation

• RxJava 3 (Add instrumentation for RxJava 3 #2794)

🌟 New library instrumentation

• RxJava 3 (Add instrumentation for RxJava 3 #2794)

📈 Enhancements

• Support sub-millisecond precision for start/end times on Java 9+ (Support sub-millisecond precision for start/end times on Java 9+ #2600)
• @WithSpan async support added for methods returning async Reactor 3.x types (Add AsyncSpanEndStrategy for Reactor 3.x instrumentation #2714)
• @WithSpan async support added for methods returning Guava ListenableFuture (Async @WithSpan Instrumentation for Guava ListenableFuture #2811)
• Semantic attributes code.namespace and code.function captured on JAX-RS internal spans (JAX-RS: add code.namespace and code.function attributes #2805)
• Context propagated to reactor-netty callbacks (Expose correct Context.current() in reactive-netty callbacks #2850)

Behavioral changes

• AWS lambda flush timeout raised to 10 seconds (Raise lambda flush timeout to 10 seconds #2855)
• SERVER span names improved for Spring MVC, Grails, Wicket, and Struts (Better server span name for Spring MVC, Grails, Wicket and Struts #2814)
• SERVER span names improved for Servlet filters (Server span naming for servlet filters #2887)
• SERVER span names improved for Resteasy (Resteasy server span naming #2900)
• SERVER span names improved for Jersey and CXF (Jersey and cxf server span naming #2919)
• JAX-RS @ApplicationPath annotation captured as part of SERVER span name (JAX-RS ApplicationPath annotation #2824)
• RequestDispatcher forward() and include() internal spans removed (Remove forward and include spans #2816)
• Raised gRPC min version supported to 1.6 in order to use new gRPC context bridge API (Raise gRPC version floor to 1.6 and use new context bridge API #2948)

🛠️ Bug fixes

• gRPC context bridging issues (gRPC trace missing #2564, Agent interfering with GCP Pub/Sub credentials? #2959)
• URL credentials of the form https://username:password@www.example.com/ no longer captured (Prevent http.url containing credentials in HttpClientTracer #2707)
• Spring MVC instrumentation can cause Spring MVC to misroute requests under some conditions (Fix Grails application error #2815)
• RxJava2 NoSuchFieldError (Fix rxjava2 NoSuchFieldError #2836)
• Duplicate http client tracing headers (Fix duplicate http client tracing headers #2842)
• Netty 4.1 listeners could not be removed by application (Fix netty 4.1 instrumentation not removing future listeners #2851)
• NPE caused in gRPC ProtoReflectionService (Only reset server context if there is a leak. #2876)
• Context leak when using Ratpack (Fix Ratpack server context propagation and enable its concurrency test #2910)
• Context leak when using Jetty (Fix context leak on jetty #2920)
• Servlet instrumentation overwrites setStatus that was set manually earlier (Servlet instrumentation overwrites setStatus that was set manually earlier #2929)
• Spans not captured on interface default methods annotated with JAX-RS annotations (Uncomment and fix JAX-RS default method tests #2930)

🧰 Tooling

• Documented how to write InstrumentationModule line by line (Writing InstrumentationModule line by line #2793)
• New instrumenter API used in JMS instrumentation (Use Instrumenter in JMS instrumentation #2803)
• Instrumenter API improvements (Instrumenter API improvements #2860)
• Muzzle checks whether used fields are actually declared somewhere (Muzzle should check whether used fields are declared somewhere #2870)
• Extracted javaagent-extension-api from tooling & spi (Extract javaagent-extension-api from tooling & spi #2879)
  • You no longer have to depend on the javaagent-tooling module to implement custom instrumentations: a new javaagent-extension-api module was introduced, containing all the necessary instrumentation classes and interfaces;
  • InstrumentationModule and TypeInstrumentation were moved to the io.opentelemetry.javaagent.extension.instrumentation package;
  • AgentElementMatchers, ClassLoaderMatcher and NameMatchers were moved to the io.opentelemetry.javaagent.extension.matcher package;
  • A new SPI AgentExtension was introduced: it replaces ByteBuddyAgentCustomizer;
  • InstrumentationModule#getOrder() was renamed to order();
  • InstrumentationModule#additionalHelperClassNames() has been removed; use isHelperClass(String) instead if you use the muzzle compile plugin. If you're not using muzzle, you can override getMuzzleHelperClassNames() directly instead;
  • InstrumentationModule#getAllHelperClassNames() has been removed; you can call getMuzzleHelperClassNames() to retrieve all helper class names instead.

🙇 Thank you

This release was possible thanks to the following contributors who shared their brilliant ideas and awesome pull requests:

@agoallikmaa
@ankitgaur-cer
@anuraaga
@asarkar
@breedx-splk
@denis111
@dkulig
@fuleow
@HaloFour
@Hangzhi
@iNikem
@jguerra
@jkwatson
@kubawach
@laurit
@mateuszrzeszutek
@necrolyte2
@pavolloffay
@pellared
@raptium
@richardstartin
@RSoodAMAT
@ryanrupp
@skoppers
@trask
@tydhot
@tylerbenson

---

This discussion was created from the release Release v1.2.0.

[asarkar]

Thank you for the continued improvements.

all artifacts ... have the -alpha suffix attached to their version number

Regarding version, my little peeve is the opentelemetry-instrumentation-bom-alpha has an alpha suffix, making it necessary to not only update the version, but also the artifact name when a stable release is available. It should be sufficient to indicate the alpha status by versioning, and not putting it in the artifact name.

[huggsboson]

Looks like a sweet release, with lots of great contributions in it. I hate to be that guy, but do you have a sense for when this will move from "alpha" (in the bom, "beta" on the tags) to GA?

[trask]

hey @huggsboson, which artifacts are you interested in particular?

[huggsboson]

We were hoping to use spring-cloud-sleuth-otel, which depends on otel-java-instrumentation (as a library, not an agent) for some of the classes in here (e.g. HttpClientTracer). They are hesitating to move to GA before you do, which I understand, so I was just trying to figure out how things are converging towards GA here.

[huggsboson]

BTW Thanks for the fast follow-up.

[trask]

ah, yes, sleuth otel depends on the opentelemetry-instrumentation-api artifact, so you will want to follow this: #2892

[huggsboson]

thank you @trask super helpful... looking forward to that refactor, it makes a lot of sense to me.