Markus Jung created TOMEE-4716:
----------------------------------
Summary: MicroProfile Health endpoints are not deployed when the
webapp declares a JAX-RS Application subclass
Key: TOMEE-4716
URL: https://issues.apache.org/jira/browse/TOMEE-4716
Project: TomEE
Issue Type: Bug
Reporter: Markus Jung
TomEEMicroProfileListener gets {{MicroProfileHealthChecksEndpoint}} into a
webapp only through class scanning ({{WebAppInfo.restClass}}). RESTService
deploys scanned classes in just two cases: in the default application when the
webapp declares no {{Application}} subclass, and inside a declared
{{Application}} whose {{getClasses()}} and {{getSingletons()}} are empty.
So the health endpoint depends on how the application configures JAX-RS:
* An {{Application}} that lists its classes (since TOMEE-3729 only those are
deployed) loses {{/health}}, {{/health/live}}, {{/health/ready}} and
{{/health/started}} entirely; all four answer 404.
* An {{Application}} that lists nothing deploys the endpoints under its own
path, e.g. {{/api/health}} for {{@ApplicationPath("/api")}}, instead of the
context root.
MicroProfile Health 4.0.1, section
[Rationale|https://download.eclipse.org/microprofile/microprofile-health-4.0.1/microprofile-health-spec-4.0.1.html#_rationale],
describes the endpoints as representing the runtime rather than one JAX-RS
application:
bq. The MicroProfile Health architecture consists of three /health/ready,
/health/live and /health/started endpoints in a MicroProfile runtime that
respectively represent the readiness, the liveness and the startup health of
the entire runtime.
Declaring an {{Application}} is the portable way to configure JAX-RS (Jakarta
RESTful Web Services 4.0, section [2.3.2
Servlet|https://jakarta.ee/specifications/restful-ws/4.0/jakarta-restful-ws-spec-4.0.html#servlet]),
so it must not switch the health endpoints off or move them.
Reproducer: a WAR with {{@ApplicationPath("/api")}} and {{getClasses()}}
returning one resource, deployed on the MicroProfile distribution; {{GET
/[context]/health}} returns 404.
Fix: container-contributed resources are tracked separately from scanned
application classes ({{WebAppInfo.containerRestClass}}) and deployed in their
own internal application at the context root, whatever {{Application}}
subclasses the webapp declares. TOMEE-3729's rule that an {{Application}} only
deploys the classes it lists is unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
