[
https://issues.apache.org/jira/browse/TOMEE-4716?focusedWorklogId=1044451&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1044451
]
ASF GitHub Bot logged work on TOMEE-4716:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 28/Sep/26 18:54
Start Date: 28/Sep/26 18:54
Worklog Time Spent: 10m
Work Description: rzo1 commented on PR #2960:
URL: https://github.com/apache/tomee/pull/2960#issuecomment-5876460949
@jungm I pushed cc6f875538 with two more cases for `HealthEndpointTest`:
- `multipleApplications` (two applications at `/api` and `/other`): passes
- `applicationAtTheContextRoot` (`@ApplicationPath("/")`, listing its
classes): **fails**, `/test/hello` answers 200 but `/test/health` is a 404
So the additional container application at `/*` collides with a user
application, which is mapped to the context root as well.
`RESTService#afterApplicationCreated` always deploys it with the prefix `"/" +
wildcard`, which is the same address as the one of the user application.
An idea would be to add the `containerRestClass` classes to the user
application, if it is mapped to the context root, instead of deploying a second
application. Can you have a look?
Two more things I noticed, but did not verify:
- The new block is guarded by `deploymentWithApplication`, so with the old
deployment (pojo configuration for a listed class or
`openejb.jaxrs.application=false`) and an application listing its classes, the
health endpoint might still be missing.
- For an application listing nothing, the endpoint moves from
`<context>/<application path>/health` to `<context>/health`. This is intended
as far as I understand, but it is worth a note in the release notes.
Issue Time Tracking
-------------------
Worklog Id: (was: 1044451)
Time Spent: 20m (was: 10m)
> 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
> Affects Versions: 11.0.0-M1, 10.2.0
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Fix For: 11.0.0, 10.3.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
