The good news is I can get all the remaining 11 failing JAX-RS tests to pass. The bad news is it breaks the Open Tracing integration.
Getting the JAX-RS tests to pass involves reverting this revert. - https://github.com/apache/tomee/commit/33d60ae7140595996e274dc4c739d31fd5b8a727 Essentially, the JAX-RS spec says it is illegal to dynamically discover providers, endpoints, etc from the classpath if the user has explicitly configured what classes they want via their Application subclass. "If either getClasses or getSingletons returns a non-empty collection then only those classes or singletons returned MUST be included in the published JAX-RS application." - https://jakarta.ee/specifications/restful-ws/3.0/jakarta-restful-ws-spec-3.0.html#automatic_discovery When we don’t adhere to that we get failures because the TCK always includes a handful of “common” providers in the war files of all the JAX-RS deployments. In most cases, however, it also supplies an Application subclass that may pick just some or none of those common providers. Some of those common providers do things like blindly return an HTTP 406 status for any exception thrown. So the short version is we need to rework our Open Tracing integration so the provider we need is not seen as something a user has supplied in their war file. I don’t know the Open Tracing code/integration, but here is where we add other providers to applications: - https://github.com/apache/tomee/blob/main/server/openejb-cxf-rs/src/main/java/org/apache/openejb/server/cxf/rs/CxfRsHttpListener.java#L578 I’m going to focus on writing a good test case that will fail if we take action on annotated providers when the application has already supplied them and document the test with all of the above. Is there someone who can take a look at reworking the Open Tracing integration? -David
