Hi David, Sorry for the bad revert and introducing a regression. I can't recall why I did it at that time.
I'll pause the @AroundConstruct implementation. The PR exists and is mostly green but one test https://ci-builds.apache.org/job/Tomee/job/master-pull-request/72/ --> org.apache.openejb.core.stateless.StatelessInvocationStatsTest.testBasic <https://ci-builds.apache.org/job/Tomee/job/master-pull-request/org.apache.tomee$openejb-core/72/testReport/org.apache.openejb.core.stateless/StatelessInvocationStatsTest/testBasic/> I spent a lot of time to try to figure out why it's now failing. But as I'm stuck, I'll pause it and create a new PR to fix the OpenTracing integration after reverting the revert. Jean-Louis -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Thu, Dec 15, 2022 at 2:52 AM David Blevins <[email protected]> wrote: > 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 > > >
