epugh commented on PR #5022:
URL: https://github.com/apache/solr/pull/5022#issuecomment-5994829535
The new JAX-RS registrations for `/overlay` and `/znodeVersion` appear to
never actually run through Jersey. `GetConfigAPI.getComponentConfig()`
(`GetConfigAPI.java:58-64`) still registers the generic
`@EndPoint(path={"/config/{component}"})` wildcard in `ApiBag`, and
`V2HttpCall.init()` resolves `ApiBag` matches before ever consulting Jersey
(`executeCoreRequest()` only invokes Jersey `if (api == null)`). Since
`"overlay"`/`"znodeVersion"` both match that wildcard, `api` is never null for
these requests, so the legacy path (`SolrConfigHandler.handleGET()`) always
wins and Jersey is never invoked — confirmed this empirically too (a request
with `Accept: application/xml` still returns JSON with no 406, which is what
you'd expect from the legacy response writer rather than real JAX-RS content
negotiation).
Functionally this is fine today since `handleGET()` now manually constructs
`GetConfig` and reuses the same logic, so responses are correct. But it means
the `ConfigApi.Get.getOverlay()`/`getZnodeVersion()` JAX-RS methods — and their
`@PermissionName` annotations — are currently dead code at the dispatch layer;
they only serve SolrJ client codegen and OpenAPI docs. Contrast with #4951,
which removed the old `@EndPoint(path={"/config"})` registration entirely when
it migrated the base path to JAX-RS, so Jersey would actually own that route.
Given the PR description already lists the remaining `/config/{component}`
values as a planned follow-up, is the intent here that the wildcard stays until
every sub-path is migrated, with the *last* one finally removing it (mirroring
#4951)? If so this is probably fine as an intermediate state — just flagging so
it's a conscious choice rather than an oversight, and so a future PR doesn't
have to rediscover this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
