Add library instrumentation for Ratpack server - #3749
Conversation
| response.contentUtf8() == SUCCESS.body | ||
|
|
||
| assertTraces(1) { | ||
| trace(0, 2 + (hasHandlerSpan(SUCCESS) ? 1 : 0)) { |
There was a problem hiding this comment.
The only difference in test logic is this sort of hasHandlerSpan branch
|
|
||
| final class RatpackGetter implements TextMapGetter<Request> { | ||
|
|
||
| RatpackGetter() {} |
There was a problem hiding this comment.
Nit: that constructor is unnecessary
There was a problem hiding this comment.
IIUC a public method in a private class is still accessible with reflection, there is no Class.setAccessible a private class is respected by javac but has no effect at runtime I think. So to ensure privateness of the constructor it has to be made private.
This of course assumes the constructor of a private class is public like public classes I assumed it is but am not sure.
|
|
||
| static final RatpackProductionErrorHandler INSTANCE = new RatpackProductionErrorHandler(); | ||
|
|
||
| private static final Logger logger = LoggerFactory.getLogger(RatpackProductionErrorHandler.class); |
There was a problem hiding this comment.
This is using "our" slf4j, not ratpack's slf4j. Is that okay?
There was a problem hiding this comment.
Hmm good point. In practice I don't think it's possible to use this class as the context should always have a error handler I think. Should I verify that and throw an exception outside of the loop that finds delegate instead of this fallback? Maybe slightly dangerous if there is some unexpected ratpack behavior though.
There was a problem hiding this comment.
Hmm, maybe just logging something would be enough? And a bit safer
…etry/instrumentation/ratpack/RatpackTracingBuilder.java Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
…ava-instrumentation into ratpack-library
2 participants
The attributes are not very complete yet, I will try to follow up to do so. One major annoyance is e.g., accessing remoteAddress involves an unstable Guava type that has had its API changed throughout the versions... On the bright side the tests are shareable.
Ideally we can use this in the javaagent instrumentation I guess, but we have our tricky chicken / egg of Netty instrumentation currently winning over any framework-specific server instrumentation if on the same thread.
On the bright side, might be able to replace the execution-related instrumentation with the library instrumentation pattern.
Will add client in the future.