JAX-RS class hierarchy scanning is incomplete and creates transaction name explosion when using EJB

Summary The JAX-RS class hierarchy scanning introduced in PR #493 does not work correctly when using EJB. EJB uses a $$$view<number> naming scheme when creating proxies, which do not get filtered out and leads to explosion of transaction names:

Additional Info I’ve tried to fix it by simply adding a condition to the JaxRsTransactionNameInstrumentation matcher:

.and(not(ElementMatchers.<TypeDescription>nameContains("$view")))

That gets rid of the $$$view explosion, but all the requests still end up in the HttpServlet30Dispatcher transaction: This shows that the current solution from PR elastic/apm-agent-java#493 is not sufficient. The problem probably comes up when dealing with generic hierarchies.

A Reproducible scenario We use a generic structure that might look complicated and intimidating at first glance, but that’s just because of the number of generic types used. We have an abstract generic endpoint, a concrete endpoint specialization, a generic endpoint/client interface and a concrete endpoint/client interface. To illustrate (Wildfly 9.0.2 btw):

1. Concrete JaxRS Endpoint:

import javax.ejb.Singleton;

@Singleton
public class ConcreteEndpoint
        extends AbstractRequestEndpoint<ClassT, ClassU, ClassE, ClassV>
        implements ConcreteClient

1. Concrete endpoint/client JaxRS web service interface definition:

@Path( "/" )
public interface ConcreteClient extends BaseRequestClient<ClassT, ClassU>

1. Abstract JaxRS endpoint:

public abstract class AbstractRequestEndpoint<T extends Class1<?>, U extends Class2<?>, E extends Class3, V extends Class4<E, U>>
        implements BaseRequestClient<T, U>

1. Generic JaxRS web service interface definition:

public interface BaseRequestClient<T extends Class1<?>, U extends Class2<?>>

Expected results We need to scan the complete jaxrs class hierarchy and find the @Path annotations, but ignore the view ejb proxies.

Maybe there are two separate issues, but I feel they are tightly coupled, so I’ve created just this one issue.

[eyalkoren]

Maybe we miss them now because the avax.ws.rs.GET/POST/... annotations are used in the methods of the proxy classes that you excluded from instrumentation? If that’s the case, the solution would be to include them in the instrumentation but not use their class name, but the actual class name they are derived from.

[felixbarny]

Closed via #600