Let's see what this one looks like https://github.com/apache/tomee/pull/987
I reverted the revert in there lol -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Thu, Dec 15, 2022 at 2:01 PM Jean-Louis Monteiro < jlmonte...@tomitribe.com> wrote: > 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 <dblev...@tomitribe.com> > 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 >> >> >>
