Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert servlet instrumentation to instrumenter api #4078

Merged
merged 18 commits into from
Sep 13, 2021

Conversation

laurit
Copy link
Contributor

@laurit laurit commented Sep 9, 2021

Part of #2713
Converts servlet, jetty and tomcat instrumentation to instrumenter api. Jetty is converted along with servlet to give an idea how server instrumenation that relies on servlet would look. Similarly tomcat is converted along with servlet to give an idea how server instrumenation that does not rely on servlet would look.
This pr deliberately avoids filling more attributes than what tracer api filled to avoid changing test and making this pr event larger. Code to fill more attributes is left commented out.

@Advice.Local("otelContext") Context context,
@Advice.Local("otelScope") Scope scope) {

Context attachedContext = tracer().getServerContext(request);
Context attachedContext = helper().getServerContext(request);
Copy link
Member

Choose a reason for hiding this comment

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

That's something definitely not for this PR, but I wonder if we can simplify this and use the shouldStart() check to verify if there's an ongoing SERVER span. Context should be propagated anyway, we shouldn't have to do that manually.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should be jetty specific. We instrument all implementations of org.eclipse.jetty.server.Handler and need to make sure that we start span only in the outermost one. I believe that we should use shouldStart to be consistent with other instrumentations, but I suspect that we can't just replace the existing code with it because shouldStart counts suppressed spans and using it for jetty would blow that number up.

Comment on lines 66 to 70
String contextPath = accessor.getRequestContextPath(request);
if (contextPath != null && !contextPath.isEmpty() && !contextPath.equals("/")) {
return context.with(ServletContextPath.CONTEXT_KEY, contextPath);
}
return context;
Copy link
Member

Choose a reason for hiding this comment

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

Idea for another PR: this could be encapsulated in ServletContextPath, kind of like ServerSpanNaming does (we should not expose ContextKeys as public vars)

* current request to context if it isn't already added. Servlet instrumentation adds it when it
* starts server span.
*/
public Context updateContext(Context context, REQUEST request) {
Copy link
Member

Choose a reason for hiding this comment

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

Could this method be merged with addServletContextPath()? Checking if current context already contains ServletContextPath.CONTEXT_KEY shouldn't probably hurt in startSpan()

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'll try to do this in a separate pr along with making ServletContextPath. CONTEXT_KEY private.

laurit and others added 3 commits September 13, 2021 17:31
…/io/opentelemetry/javaagent/instrumentation/servlet/ServletRequestContext.java

Co-authored-by: Mateusz Rzeszutek <[email protected]>
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a comment

Choose a reason for hiding this comment

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

🚀 🎉

@trask
Copy link
Member

trask commented Sep 13, 2021

👏 thx @laurit (and @mateuszrzeszutek for reviewing)!

I'm going to go ahead and merge to unblock follow-on work, and I'll review in more detail later

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