-
Notifications
You must be signed in to change notification settings - Fork 867
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
Restlet instrumentation #3946
Restlet instrumentation #3946
Conversation
instrumentation/restlet/restlet-core-1.1/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
...va/io/opentelemetry/javaagent/instrumentation/restlet/v1_1/RestletInstrumentationModule.java
Outdated
Show resolved
Hide resolved
...brary/src/main/java/io/opentelemetry/instrumentation/restlet/v1_1/RestletExtractAdapter.java
Outdated
Show resolved
Hide resolved
...ary/src/main/java/io/opentelemetry/instrumentation/restlet/v1_1/RestletHttpServerTracer.java
Outdated
Show resolved
Hide resolved
...c/main/groovy/io/opentelemetry/instrumentation/restlet/v1_1/AbstractRestletServerTest.groovy
Outdated
Show resolved
Hide resolved
instrumentation/restlet/restlet-core-1.1/library/src/test/groovy/RestletServerTest.groovy
Outdated
Show resolved
Hide resolved
.../main/java/io/opentelemetry/javaagent/instrumentation/restlet/v1_1/RouteInstrumentation.java
Outdated
Show resolved
Hide resolved
...main/java/io/opentelemetry/javaagent/instrumentation/restlet/v1_1/ServerInstrumentation.java
Outdated
Show resolved
Hide resolved
cf73b9c
to
3e095a5
Compare
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Outdated
Show resolved
Hide resolved
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Outdated
Show resolved
Hide resolved
...c/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletNetAttributesExtractor.java
Outdated
Show resolved
Hide resolved
.../main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletHttpAttributesExtractor.java
Outdated
Show resolved
Hide resolved
.../main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletHttpAttributesExtractor.java
Outdated
Show resolved
Hide resolved
...0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletSingletons.java
Outdated
Show resolved
Hide resolved
...0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletSingletons.java
Outdated
Show resolved
Hide resolved
...main/java/io/opentelemetry/javaagent/instrumentation/restlet/v1_0/ServerInstrumentation.java
Outdated
Show resolved
Hide resolved
.../main/java/io/opentelemetry/javaagent/instrumentation/restlet/v1_0/RouteInstrumentation.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice! I left just a few (mostly minor) comments.
...ary/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletServerSpanNaming.java
Outdated
Show resolved
Hide resolved
...-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletTracing.java
Show resolved
Hide resolved
...ary/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletServerSpanNaming.java
Outdated
Show resolved
Hide resolved
...-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletTracing.java
Outdated
Show resolved
Hide resolved
...brary/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/RestletTracingBuilder.java
Outdated
Show resolved
Hide resolved
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Outdated
Show resolved
Hide resolved
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Outdated
Show resolved
Hide resolved
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Outdated
Show resolved
Hide resolved
...t-1.0/library/src/main/java/io/opentelemetry/instrumentation/restlet/v1_0/TracingFilter.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Thanks!
return; | ||
} | ||
|
||
// Restlet suppresses exceptions and sets the throwable in status |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
public Iterable<String> keys(Request carrier) { | ||
return HeadersAdapter.getHeaders(carrier).getNames(); | ||
} | ||
|
||
@Override | ||
public String get(Request carrier, String key) { | ||
return HeadersAdapter.getValue(carrier, key); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest inlining the HeadersAdapter methods and deleting the HeadersAdapter class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I think it's not necessary to keep them separate
public Instrumenter<Request, Response> getServerInstrumenter() { | ||
return serverInstrumenter; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe just getInstrumenter()
if we don't need to distinguish between client and server instrumenter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm planning on adding client instrumentation in the future, so I'd prefer to leave the current naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sense 👍
/* | ||
* Copyright The OpenTelemetry Authors | ||
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/* | |
* Copyright The OpenTelemetry Authors | |
* SPDX-License-Identifier: Apache-2.0 | |
*/ |
|
||
@Override | ||
boolean testException() { | ||
false //Filter's afterHandle does not execute if exception was thrown in the next restlet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if afterHandle
is not executed, will the Scope that was started in beforeHandle
be left open (and the Context left bound to the thread)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after some investigation and looking into Restlet's StatusFilter
I found a way to make afterHandle
execute even if an exception was thrown, so the Scope will be safely closed in every case now
import static io.opentelemetry.instrumentation.test.base.HttpServerTest.ServerEndpoint.REDIRECT | ||
import static io.opentelemetry.instrumentation.test.base.HttpServerTest.ServerEndpoint.SUCCESS | ||
|
||
abstract class AbstractRestletServerTest extends HttpServerTest<Server> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
try { | ||
super.doHandle(request, response); | ||
} catch (Throwable t) { | ||
response.setStatus(new Status(Status.SERVER_ERROR_INTERNAL, t)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could implement the whole instrumentation inside doHandle
to avoid modifying the response object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without setting status this way, the throwable is not propagated and we get a response with status of 200, not 500. My approach based on StatusFilter.
I can move instrumentation code to doHandle
, leaving this line as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. How about you move the instrumentation code to doHandle
and use the StatusFilter
in library instrumentation tests? We generally want an instrumentation to be as transparent as possible - I agree that returning 200 for unhandled exceptions is a bit weird and unintuitive, but as instrumentation authors we should avoid changing this default behavior on our whim. If a user wants to return 500s instead then they're going to use StatusFilter
anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, thanks for the explanation!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx @Enkelian!
Beginning of Restlet instrumentation - issue #3661.