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

Fix scala/play2.6 support #94

Closed
wants to merge 0 commits into from
Closed

Fix scala/play2.6 support #94

wants to merge 0 commits into from

Conversation

junder31
Copy link
Contributor

Overview

Monitoring on scala/play2.6.18 was not working when I initially installed the newrelic agent. I found that the later versions of play2.6 deprecated the getHandlerFor method on the Server trait and used the Server object similar to how the play2.7 integration works. Since the signatures for the getHandlerFor vary between the trait and object I had to do some refactoring to support both methods.

Testing

I added a new tests for play2.6.18 which uses the object method rather than the trait.

Checks

[ ] Are your contributions backwards compatible with relevant frameworks and APIs? No
[ ] Does your code contain any breaking changes? No
[ ] Does your code introduce any new dependencies? No

@CLAassistant
Copy link

CLAassistant commented Oct 27, 2020

CLA assistant check
All committers have signed the CLA.

@tspring
Copy link
Contributor

tspring commented Oct 27, 2020

@junder31 Thanks for PR! Looks like the Server trait doesn't exist in versions 2.6.0-2.6.11, which causes the instrumentation to not match those versions. If there's another common instrumentation point you could match that would be awesome, otherwise I think we'll need to split the module into a version for 2.6.0 and one for 2.6.12+. There's a @SkipIfPresent API you can use to avoid both loading. Here's an example
Let us know if you've any questions

@junder31
Copy link
Contributor Author

@tspring Thanks for the feedback. I couldn't identify any good option to make use of the @SkipIfPresent annotation. I decided to opt for splitting the integration into multiple modules. It looks like the first play2.6 version that matched the signature I instrumented was 2.6.13 which was also when the deprecation warning was added. The existing integration should work for all 2.6.0-2.6.12 and 2.6.13+ all should be supported with the new module I have contributed.

@tspring
Copy link
Contributor

tspring commented Oct 28, 2020

@junder31 Thanks again, we appreciate it! I'll take a look at this tomorrow hopefully.

@junder31 junder31 force-pushed the main branch 2 times, most recently from 898985e to eefc23c Compare October 29, 2020 10:11
@tspring
Copy link
Contributor

tspring commented Oct 29, 2020

@junder31 Apologies for the confusion and lack of documentation surrounding our instrumentation Weaver APIs. The @SkipIfPresent annotation is necessary to prevent both play-2.6 and play-2.6.13 from applying at the same time. If you could add a class like this to the old 2.6 instrumentation it should work:


import com.newrelic.api.agent.weaver.SkipIfPresent;

@SkipIfPresent
public class ServerDebugInfo$ {
}

FWIW, this project is what we use to check instrumentation matching: https://github.com/newrelic/newrelic-gradle-verify-instrumentation.

Copy link
Contributor

@tspring tspring left a comment

Choose a reason for hiding this comment

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

Would you mind rebasing this on a branch and commit message reflective of the change?

@junder31
Copy link
Contributor Author

ServerDebugInfo

@tspring Thanks for the help. Is there an easy way to identify candidate classes for the @SkipIfPresent annotation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants