HWKAPM-826 - RESTeasy rules for getting the URL template

[jpkrohling]

No description provided.

[jpkrohling]

With this patch, the captured template for a RESTeasy endpoint is:
http://localhost:8080/jaxrs-uri-template-1.0-SNAPSHOT/app/download/file/{path:.+}

And this is how it looks like:

Should the protocol, hostname and port be removed?

[objectiser]

@jpkrohling I think its ok to have a REST easy specific solution for now - two points:

• the rule name/file should be RESTeasy instead of jaxrs
• the template should not include the host/port - just the path, but it looks like it is using a deployment path, i.e. /app/download/ (and possibly the 'file' path) - this does not look part of the actual path for the http endpoint - so can it be stripped out?

[jpkrohling]

Agree on point 1, but not sure I follow your point 2.

This is how the path is composed:

Full URL: http://localhost:8080/jaxrs-uri-template-1.0-SNAPSHOT/app/download/file/aa/bb/cc

Protocol, host and port will be stripped out.
/jaxrs-uri-template-1.0-SNAPSHOT -- this is the Servlet Context (either from jboss-web.xml or derived from the WAR file name)
/app -- it's JAX-RS application's base path, defined as @ApplicationPath("/app")
/download -- is the @Path from the JAX-RS resource endpoint (class-level annotation), defined as @Path("/download")
/file -- is the resource method @Path, defined as @Path("file/{path:.+}")
aa/bb/cc is the path parameter to the resource method, defined as @PathParam("path")

So, besides the protocol, host and port, should I also leave the context out? Like this, /app/download/file/aa/bb/cc?

[objectiser]

Not that is fine then. It was possibly just the example used which made it look more like a physical deployment location.

[jpkrohling]

This is how it looks like with this extra commit. If that looks alright, I'll squash and update the PR.

[objectiser]

@jpkrohling Looks good, just a couple of things:

• minor point - could you move the apm-resteasy.btm up one level, as the resteasy folder would only have a single file
• as with HWKAPM-817 Add OT agent instrumentation rules for EJB #738 this could do with an arquillian test with a RESTeasy service actually triggering the rule and extracting the template

[jpkrohling]

I'm pushing two new commits: one with the move of the resteasy rule, and another with the Arquillian changes. The second is not finished yet, as it depends on having access to the span from within the REST endpoint. If it's not possible to get it there, I will need to rewrite the test to get the required data from somewhere else. Any ideas on that?

[objectiser]

@jpkrohling Was thinking that an additional 'test' rule could be added to get the template and add it to the request attributes, but unfortunately the Span interface does not provide access to the tags - only operations to set them.

The other possibility would be to query the reported trace data and check the properties reported against the relevant node/span?

[objectiser]

@jpkrohling This may be the best general approach for testing rule - by verifying the trace data they produce? Its what the current agent rule tests do.

[objectiser]

The javaagent command line options would also need to be provided to trigger the rules in the wildfly server.

[objectiser]

Created https://issues.jboss.org/browse/HWKAPM-853 to implement arquillian tests for OT agent rules that require a server to be launched.

[objectiser]

@jpkrohling Thanks!