Hi all,

I spent some time debugging more and going the git bisec

$ git bisect good
> fab4b24b0c3d403666cc2ff3b0c3b58b47f7816b is the first bad commit
> commit fab4b24b0c3d403666cc2ff3b0c3b58b47f7816b
> Author: David Blevins <[email protected]>
> Date:   Sat Apr 24 16:23:19 2021 -0700
>
>     TOMEE-3729 Do not scan classpath for @Provider when there is a JAX-RS
> Application
>
>  .../java/org/apache/openejb/server/rest/RESTService.java | 16
> ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
>

https://issues.apache.org/jira/browse/TOMEE-3729

The comment in the ticket says

> We should instead scan just the classes listed by the JAX-RS Application
> subclass.
>
> To enable the previous behavior of scanning all the classpath even when
> there is a JAX-RS Application subclass, set the system property
> `openejb.jaxrs.providers.auto` to `true`
>

I don't think this is good even though it explains the problem.
I tested with the system property without pushing because I double checked
the specification and it does not seem accurate.

I would revert but David if you could clarify a bit, that'd be great.
Spec section
https://jakarta.ee/specifications/restful-ws/3.0/jakarta-restful-ws-spec-3.0.html#providers

All *application-supplied* providers implement interfaces in the JAX-RS API
> and MAY be annotated with @Provider for automatic discovery purposes; the
> integration of pre-packaged providers into the JAX-RS runtime is
> implementation dependent.
>

It does not say that when there is an application we shouldn't scan. It
just says they may not be annotated but we still have to use them if
defined in application.

4.1.1. Automatic Discovery
>
> The annotation @Provider is used by a JAX-RS runtime to automatically
> discover provider classes via mechanisms such as class scanning. A
> JAX-RS implementation that supports automatic discovery of classes MUST
> process only those classes that are annotated with @Provider.
>
This part is also clear. All annotated providers must be scanned.

If it breaks the TCK, we may have an issue there.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Wed, Jun 30, 2021 at 11:51 AM Jean-Louis Monteiro <
[email protected]> wrote:

> Hi all,
>
> With Richard we've been looking at the TCK failures in MicroProfile.
> I did a couple of experiments trying to pin down where we broke the thing.
>
> First, I tried with 8.0.0 and it was working, so it's really recently that
> we broke it.
> Debugging seems to show that MicroProfile endpoints such as /openapi
> aren't deployed anymore.
>
> I reverted all the shaded and patching thingy and used regular CXF jars
> after rebuilding everything and it fails as well.
>
> I'm going to do a git bysec, rebuild and try to see if I can determine
> what's going on.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Reply via email to