[ 
https://issues.apache.org/jira/browse/TOMEE-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100872#comment-18100872
 ] 

Markus Jung commented on TOMEE-4643:
------------------------------------

Clarification on where this gap actually sits, after reading the CXF 4.2.2 
sources.

*CXF does not implement ServiceLoader-based Feature/DynamicFeature discovery at 
all.* Grepping the whole {{rt/}} and {{core/}} trees of the {{cxf-4.2.2}} tag 
for {{ServiceLoader.load(...)}} on {{jakarta.ws.rs.core.Feature}} / 
{{jakarta.ws.rs.container.DynamicFeature}} returns nothing. The only 
{{ServiceLoader}} uses in the JAX-RS frontend are for unrelated SPIs 
({{Instantiator}} in {{ConfigurableImpl}}, 
{{JAXRSServerFactoryCustomizationExtension}}). The {{getFeatures(...)}} calls 
in {{CXFNonSpringJaxrsServlet}} read CXF {{Feature}}s from servlet init-params, 
which is a different mechanism.

So the reason CXF's own TCK run passes {{featureIsRegisteredTest}} / 
{{dynamicFeatureIsRegisteredTest}} is *the container, not CXF*: 
{{tck/cxf-tck/pom.xml}} deploys onto GlassFish 8 
({{arquillian-glassfish-managed}}, {{glassfish.container.version}} 8.0.2). 
GlassFish's deployment layer performs the {{META-INF/services}} scan and hands 
the resolved classes to the JAX-RS runtime as pre-resolved providers, so CXF 
never has to do the lookup.

TomEE has no equivalent layer — {{RESTService}} / {{CxfRsHttpListener}} 
assemble the provider list themselves — so nothing performed the lookup and 
such features silently never registered. That is why the fix belongs in TomEE 
rather than upstream.

Two corrections to the original description while we are here:
* The "Related upstream tracking: CXF-9005" line is misleading. Whatever 
CXF-9005 changed, it is not ServiceLoader-based Feature discovery in the CXF 
codebase — there is no such code in 4.2.2. This issue is not blocked on, or 
fixed by, anything upstream.
* Consequently there is no CXF version to upgrade to that would resolve this on 
its own.

Note the contrast with TOMEE-4659 (split out of this issue): there, CXF gets 
the behaviour right and TomEE's integration breaks it. Here, neither CXF nor 
TomEE implements the behaviour, and GlassFish is what covers for CXF. Both are 
container-integration gaps, just mirrored.

> REST 3.1: no META-INF/services discovery for Feature/DynamicFeature
> -------------------------------------------------------------------
>
>                 Key: TOMEE-4643
>                 URL: https://issues.apache.org/jira/browse/TOMEE-4643
>             Project: TomEE
>          Issue Type: Bug
>            Reporter: Markus Jung
>            Assignee: Markus Jung
>            Priority: Major
>
> TomEE does not scan {{META-INF/services}} for {{Feature}} and 
> {{DynamicFeature}} implementations. The REST 3.1 spec asks the runtime to 
> pick these up through the standard Java {{ServiceLoader}} mechanism at deploy 
> time. Because TomEE (through CXF) skips this step, a {{Feature}} or 
> {{DynamicFeature}} packaged this way never registers, and any behavior it 
> should add to the request or response pipeline never runs.
> Related upstream tracking: CXF-9005.
> This gap sits in TomEE's JAX-RS/CXF integration, not in the TCK or the test 
> harness.
> Related to TOMEE-4321, the open umbrella ticket for JAX-RS TCK failures.
> NOTE: this issue originally also covered a second, unrelated gap — a request 
> to an unmatched {{@Path}} returning HTTP 405 instead of 404. That has a 
> different root cause and has been split out to TOMEE-4659.
> h2. Steps to reproduce / TCK reference
> Suite: Jakarta RESTful Web Services 4.0 TCK 
> ({{jakarta.ws.rs:jakarta-restful-ws-tck:4.0.1}}).
> Feature/DynamicFeature discovery:
> * 
> {{ee/jakarta/tck/ws/rs/jaxrs31/spec/extensions/JAXRSClientIT.java#featureIsRegisteredTest}}
> * 
> {{ee/jakarta/tck/ws/rs/jaxrs31/spec/extensions/JAXRSClientIT.java#dynamicFeatureIsRegisteredTest}}
> Both are excluded via the surefire {{<excludes>}} block in 
> {{tck/jax-rs/jax-rs-tests/pom.xml}} (as a whole-class exclusion of 
> {{**/jaxrs31/spec/extensions/JAXRSClientIT.java}}, since surefire cannot 
> exclude individual methods). Remove that exclusion once fixed and the suite 
> should pass those tests.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to