[
https://issues.apache.org/jira/browse/TOMEE-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jung updated TOMEE-4643:
-------------------------------
Description:
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.
was:
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.
Second, when a request path matches a method only declared on a superclass
through {{@Path}}, and not on the subclass that serves the resource, TomEE
answers with HTTP 405 (Method Not Allowed). The spec requires 404 (Not Found)
in this case, since the subclass does not expose a matching resource method at
that path. TomEE's path-matching logic treats the superclass mapping as present
but the method as wrong, when it should treat the path itself as absent for the
subclass.
Both gaps sit 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 — this
issue reports two specific, well-defined gaps under that umbrella.
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}}
Superclass {{@Path}} matching (405 vs 404):
*
{{ee/jakarta/tck/ws/rs/spec/resource/annotationprecedence/subclass/JAXRSClientIT.java#incorrectPathOnClassTest}}
All three are excluded in {{runner-standalone/exclusions/rest.txt}} in the
apache/tomee-tck harness repo. Remove the matching lines once fixed, and the
suite should pass those tests without the exclusion.
Summary: REST 3.1: no META-INF/services discovery for
Feature/DynamicFeature (was: REST 3.1: no META-INF/services discovery for
Feature/DynamicFeature; superclass @Path returns 405 not 404)
> 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)
