Skip to content

Conversation

@laurit
Copy link
Contributor

@laurit laurit commented Nov 27, 2025

Supersedes #15188

@@ -0,0 +1,43 @@
plugins {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed testing to javaagent-testing for some reason this file didn't register as being moved :(


/** Sets the status extractor for server spans. */
@CanIgnoreReturnValue
public ServletTelemetryBuilder setStatusExtractor(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently ServletRequestContext is in internal package we have to either move it out of the internal or alternatively we could change the signature to UnaryOperator<SpanStatusExtractor<HttpServletRequest, HttpServletResponse>>. The wrappers are there mostly so we could share code between servlet 3 & 5 instrumentations. ServletResponseContext has some fields but ServletRequestContext doesn't have any and is probably there only for symmetry. If we don't use the wrappers in the signature then the downside is that conversion will be needed

    builder.setStatusExtractor(
        inputExtractor -> {
          SpanStatusExtractor<HttpServletRequest, HttpServletResponse> outputExtractor =
              statusExtractor.apply(
                  (spanStatusBuilder, request, response, error) ->
                      inputExtractor.extract(
                          spanStatusBuilder,
                          new ServletRequestContext<>(request),
                          response == null ? null : new ServletResponseContext<>(response),
                          error));
          return (spanStatusBuilder, requestContext, responseContext, error) ->
              outputExtractor.extract(
                  spanStatusBuilder,
                  requestContext.request(),
                  responseContext == null ? null : responseContext.response(),
                  error);
        });

@trask which way would you prefer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed wrapper types from the ServletTelemetryBuilder public api to try it out

jvmArgs("-XX:+IgnoreUnrecognizedVMOptions")
}

if (findProperty("testLatestDeps") as Boolean) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not using otelJava because that would apply to the main source too which would break the instrumentation for libraries that only work with java 8 when tests are run with -PtestLatestDeps=true. The same approach could be used to get rid of the javaagent-testing module and move the tests back to javaagent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add this as a code comment?

@laurit laurit marked this pull request as ready for review December 1, 2025 08:10
@laurit laurit requested a review from a team as a code owner December 1, 2025 08:10
otelRequest.asyncException = error;
}
} else {
instrumenter.end(context, requestContext, responseContext, error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any options to enable customizing the metric attributes for the metrics generated by this instrumenter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We pass all the attributes produced by the AttributesExtractors to the metrics. Users can choose which of the attributes are used by configuring a metrics view.

}

/** Returns a new {@link Filter} for producing telemetry. */
public Filter newFilter() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be helpful for consumers of this library to have a no-arg-constructor public implementation of Filter that can be added directly to web.xml, but it would not be difficult for them to implement it themselves so I don't see this as a blocker.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Providing a filter like that is problematic because it raises the questions where does the OpenTelemetry instance come from and how is that filter configured. With the current api user can have their own filter which creates the telemetry filter and delegates to it. This way users are responsible for providing OpenTelemetry instance and the configuration is handled in the builder class as for our other library instrumentations.
If you believe that a dedicated filter would be useful you are welcome to work on this in a subsequent PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand. It is just a mild suggestion that I wanted to mention. I'll consider contributing something with default config values and GlobalOpenTelemetry later on.

Copy link
Member

@tylerbenson tylerbenson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate you taking the time to implement this. From what I can tell, this is a reasonable implementation and works as I expect. I look forward to this being released.

Thanks!

@trask trask added this to the v2.23.0 milestone Dec 2, 2025
@trask trask requested a review from Copilot December 3, 2025 18:56
Copilot finished reviewing on behalf of trask December 3, 2025 18:57
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds library instrumentation for Java Servlet 3.0+ by extracting servlet instrumentation code from javaagent-only modules into shared library modules. This enables users to manually instrument their servlet applications without requiring the Java agent.

Key changes:

  • Creates new library modules for servlet instrumentation (servlet-common:library, servlet-javax-common:library, servlet-3.0:library)
  • Refactors servlet classes from javaagent packages to library internal packages
  • Consolidates servlet test classes into shared testing modules with parameterized tests
  • Updates dependent modules to use the new library modules instead of javaagent modules

Reviewed changes

Copilot reviewed 126 out of 134 changed files in this pull request and generated no comments.

Show a summary per file
File Description
settings.gradle.kts Adds new library and testing module declarations
instrumentation/servlet/servlet-3.0/library/* New library instrumentation module with public API (ServletTelemetry, ServletTelemetryBuilder)
instrumentation/servlet/servlet-common/library/* Shared servlet library code moved from javaagent with internal packages
instrumentation/servlet/servlet-3.0/testing/* Refactored test modules into shared base classes
instrumentation/servlet/servlet-3.0/javaagent-testing/* New javaagent-specific test module
instrumentation/servlet/servlet-javax-common/javaagent/build.gradle.kts Deleted - functionality moved to library module
Multiple build.gradle.kts files Updated dependencies from servlet-javax-common:javaagent to library modules
instrumentation/tomcat/, instrumentation/jetty/, etc. Updated imports to use new servlet internal package locations
testing-common/.../AbstractHttpServerTest.java Changed setupOptions visibility from package-private to protected
docs/supported-libraries.md Updated servlet documentation with library module link

@trask trask merged commit 671b2e9 into open-telemetry:main Dec 3, 2025
85 checks passed
@trask
Copy link
Member

trask commented Dec 3, 2025

🎉

Thanks for reviewing @tylerbenson!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants