+1 to try and stay on jdk 11 and let the users upgrade to jdk 17 by
themselves if they really want Spring 6

On Mon, 19 Dec 2022 at 09:52, Jean-Louis Monteiro <[email protected]>
wrote:

> Quick note on CXF.
>
> This is a vote to release CXF 4.0.0.    This is a major release that
> > completely changes the API from using the older javax.* packages to using
> > the jakarta.* versions.   It also updates everything to more modern
> > dependencies (Jetty 11, Spring 6, etc…).   This also raises the minimum
> JDK
> > level to Java 11, but in some cases Java 17  is required (example: Spring
> > 6/SpringBoot 3).
> >
>
> For TomEE 10.x maybe so we don't delay TomEE 9 final, we should try to use
> CXF 4.0. It looks like the Java 17 minimum required Java is only for some
> modules. We don't use Spring integration as we wire CXF up in the code
> itself. Maybe it would work.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Dec 15, 2022 at 4:56 PM Jean-Louis Monteiro <
> [email protected]> wrote:
>
> > 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 <
> > [email protected]> 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 <[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
> >>>
> >>>
> >>>
>

Reply via email to