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

HWKAPM-817 Add OT agent instrumentation rules for EJB #738

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

objectiser
Copy link
Contributor

No description provided.

@objectiser
Copy link
Contributor Author

objectiser commented Jan 13, 2017

@pavolloffay @jpkrohling Could review please?

Notes:

  • This PR includes basic instrumentation rules for demarcating Wildfly/EAP EJB usage. So is not a general EJB instrumentation approach - this could be investigated as a separate jira if there is a need (possibly using some additional class instrumentation outside byteman rules, leveraging the annotations).
  • Currently no tests, as existing agent tests do not rely on a separate server to be launched. Not sure whether it is work adding a specific test for this, or other approach would be to produce an example that includes EJBs, and test it in the instrumentation framework? Has been manually tested currently.

Copy link
Contributor

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

I think an automated test would be beneficial to this. This is the kind of feature that might break without us realizing for some time.

IF !$2.getName().equals("onMessage")
DO
startSpanWithParent(getTracer().buildSpan($2.getName())
.withTag("EJB.uri", truncateAtDelimiter(simpleClassName($1),"$$$")),
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a more reliable way to get the proxied bean name? Also, is this the bean name (interface), or the implementing class name? Would it be interesting to store also the kind of bean being invoked (Home, Local Home, Remote)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Its the implementing class name. I'll investigate, I originally copied some byteman rules someone else had created for tracking EJB usage.

@objectiser
Copy link
Contributor Author

Agree automated is better, but depends whether we should have a set of tests that depend on a separate server to be launched (not sure how many of the agent rules would require this), or test by example (i.e. create a JEE example that incorporates EJBs, and verify the trace data using the instrumentation-test framework)?

If first option, we then have the choice between arquillian, which we haven't used so far, or just using the wildfly maven plugin?

Copy link
Member

@pavolloffay pavolloffay left a comment

Choose a reason for hiding this comment

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

LGTM 👍

As Juca mentioned, have tests for this would be great.

@@ -435,4 +435,8 @@ protected TraceContext getTraceContext() {
}
return state;
}

public String toString() {
return super.toString() + "[operationName=" + getOperationName() + " state=" + state() + "]";
Copy link
Member

Choose a reason for hiding this comment

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

super does not define toString() if it's added we end up with two operation names.

@pavolloffay
Copy link
Member

If it can be tested with arqullian, it's better than instrumentation-framework I think. At least faster.

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