SOLR-16396: Migrate GET /config/requestHandler to JAX-RS by jaykay12 · Pull Request #5168 · apache/solr

jaykay12 · 2026-10-16T06:55:34Z

https://issues.apache.org/jira/browse/SOLR-16396

Description

Migrate GET /config/requestHandler to JAX-RS

Already landed / related:

Full GET /config: SOLR-16396 | Migration of Get Config V2 API to JAX-RS construct #4951
Overlay / znodeVersion: SOLR-16396 | Migrate GET /config/overlay and GET /config/znodeVersion to JAX-RS. #5022
4 previous sections: SOLR-16396 | Migrate GET config sections updateHandler, directoryFactory, indexConfig, and codecFactory to JAX-RS. #5023
3 more sections: SOLR-16396 | Migrate GET config sections query, searchComponent & queryResponseWriter to JAX-RS #5125

Solution

AI Disclaimer: Used Cursor for Approach formulation, code is fully vetted & reviewed by me.

Tests

GetConfigTest covers the scenarios.

Checklist

Please review the following and check all that apply:

I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
I have created a Jira issue and added the issue ID to my pull request title.
I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
I have developed this patch against the main branch.
I have run ./gradlew check.
I have added tests for my changes.
I have added documentation for the Reference Guide
I have added a changelog entry for my change

jaykay12

self-review ✅
@epugh Can you have a look into this PR & trigger the workflows once?

once codewise lgtm is there, i will do the local testing.

jaykay12 · 2026-10-16T06:57:37Z

+        @QueryParam("componentName")
+            @Parameter(description = "Name of the specific request handler")
+            String component,


this is the most restful we can get here.
we can't use PathParams here like we have used for /searchComponents & /queryResponseWriters.

jaykay12 · 2026-10-16T07:03:51Z

Testing for requestHandler

Type	Url
V1 API	http://localhost:8983/solr/techproducts/config/requestHandler
Current V2 API	~~http://localhost:8983/api/collections/techproducts/config/requestHandler~~
Proposed V2 API	http://localhost:8983/api/collections/techproducts/config/requestHandlers
-	-
V1 API with expandParams=true(false by default)	http://localhost:8983/solr/techproducts/config/requestHandler?expandParams=true
Current V2 API with expandParams=true	~~http://localhost:8983/api/collections/techproducts/config/requestHandler?expandParams=true~~
Proposed V2 API with expandParams=true	http://localhost:8983/api/collections/techproducts/config/requestHandlers?expandParams=true
-	-
V1 API with filter	http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/update/json/docs
Current V2 API with filter	~~http://localhost:8983/api/collections/techproducts/config/requestHandler?componentName=/update/json/docs~~
Proposed V2 API with filter	http://localhost:8983/api/collections/techproducts/config/requestHandlers?componentName=/update/json/docs
-	-
V1 API with filter & expandParams	http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/update/json/docs&expandParams=true
Current V2 API with filter & expandParams	~~http://localhost:8983/api/collections/techproducts/config/requestHandler?componentName=/update/json/docs&expandParams=true~~
Proposed V2 API with filter & expandParams	http://localhost:8983/api/collections/techproducts/config/requestHandlers?componentName=/update/json/docs&expandParams=true

type	main branch	feature branch
v1 api - all
-	-	-
v2 api - all
-	-	-
v1 api - filtered
-	-	-
v2 api - filtered
-	-	-
v1 api - filtered & expandParams
-	-	-
v2 api - filtered & expandParams

epugh

double check some of the chnages I made in our last PR together, I think they are patterns we need on this one too!

so excited!

epugh · 2026-10-16T11:49:53Z

            int expectedParamsVersion);

+    @GET
+    @Path("/requestHandler")


doiuble check sheet, but I think this is now plural? "requestHandlers"????

done.

V2 is @path("/requestHandlers") (plural), matching the sheet.
V1 stays singular requestHandler.

epugh · 2026-10-16T11:50:17Z


+    @GET
+    @Path("/requestHandler")
+    @StoreApiParameters


what does @StoreApiParameters mean?

i got introduced to this annotation when doing TaskAPI JAX-RS migrations, this annotations automatically wires the cores/collection & indexName stuffs in the v2 APIs endpoints.

Got this understanding confirmed via Cursor as well now.

epugh · 2026-10-16T11:50:36Z

+        summary = "Fetch request handlers (including implicit handler)",
+        tags = {"config"})
+    ConfigInfoResponse getRequestHandler(
+        @QueryParam("componentName")


i think this is now a path param as well....

Stated the reasoning here in my self-review: #5168 (comment)

We can’t put the handler name in the path the way we do for searchComponents/{name} / queryResponseWriters/{name}.

Request-handler names are paths themselves (/select, /update/json/docs, /admin/ping, …). A @PathParam would be a single segment, so names with / break routing (and encoding gets ugly).

So for request handlers we keep filtering via query param:
GET .../config/requestHandlers?componentName=/update/json/docs

jaykay12 · 2026-10-16T17:51:35Z

Thanks @epugh for the quick review! I have addressed the comments.
Local testing is done ✅

PackageToolTest is failing right now, mostly looks like it is due to "requestHandler" -> "requestHandlers" in the v2 endpoint, but I am not yet able to debug & fix it. Trying more.

…/jaykay12/solr into pr/5168 # Conflicts: # changelog/unreleased/SOLR-16396-config-query.yml # solr/api/src/java/org/apache/solr/client/api/endpoint/ConfigApi.java # solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java # solr/core/src/java/org/apache/solr/handler/admin/api/GetConfig.java # solr/core/src/test/org/apache/solr/handler/admin/api/GetConfigTest.java

Solr forwards a v2 request to the node that actually hosts the target collection using the short "/c/{collection}/..." path alias (see HttpSolrCall#sendRemoteProxy), but Constants.INDEX_PATH_PREFIX's JAX-RS @path regex only recognized "cores" or "collections", not "c". Any JAX-RS resource built on that prefix therefore 404'd with "Cannot find API for the path" whenever a request needed to be proxied cross-node. Reproduced with a new 2-node test in GetConfigSolrCloudTest that deliberately sends a GET /config/overlay request to the node that does NOT host the collection's only replica, then fixed by accepting "c" as an alias for "collections" in the path regex. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01RzzUgiebQ8ZhhgE2E7ZZU5

CI builds with -Werror, and errorprone flags comparing JettySolrRunner instances with != instead of .equals(). Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01RzzUgiebQ8ZhhgE2E7ZZU5

…equestHandler

jaykay12 · 2026-10-19T17:01:48Z

@epugh this looks fine to me now, this PR has changes from the fix PR as well now & the test passes locally.
Can you please trigger the workflows here? I will keep an eye.

epugh · 2026-10-20T02:15:18Z

done

…/jaykay12/solr into pr/5168

@QueryParam

…"boolean" values exposed 1. PackageManager.verify() builds its verify-command URL by taking the path straight from repository.json's template (e.g. /api/collections/${collection}/config/requestHandlers?componentName=${RH-HANDLER-PATH}&meta=true) and passing that whole string, including the embedded ?..., as the path argument to GenericSolrRequest, with an empty separate params object. 2. HttpJettySolrClient.makeRequest() builds GET requests as url + wparams.toQueryString() — and toQueryString() always starts with a literal ?. Since url already contains its own ?..., this produces a malformed URL with two ? characters: ...requestHandlers?componentName=/mypath2&meta=true?wt=json. 3. Per the URL spec, everything after the first ? is one query string. Splitting on & gives meta = "true?wt=json" — a garbled value, not "true". 4. V1's parameter binding (SolrParams.getBool → StrUtils.parseBool) uses startsWith("true"), so it's lenient enough to still resolve "true?wt=json" to true — masking the bug for years on the old /config/requestHandler endpoint. 5. V2's JAX-RS @QueryParam boolean meta binding does an exact match, so "true?wt=json" fails to parse as true and silently resolves to false — the test fixture's upgrade to the new plural /config/requestHandlers endpoint is what exposed this for the first time.

# Conflicts: # solr/core/src/test/org/apache/solr/handler/admin/api/GetConfigSolrCloudTest.java

…p plumbing - PackageUtils.getJsonStringFromUrl now reuses the existing, more correct SolrRequestParsers.parseQueryString (which %-decodes values) instead of a hand-rolled split("&")/split("=") parser that didn't. - GetConfig.requestHandlersWithImplicits had two incompatible calling conventions: buildConfigMap relied on it mutating a full config-map wrapper in place, while getRequestHandler only used its return value and threw the wrapper away. Both callers now extract the requestHandler submap themselves before calling it, so the shared method has a single, consistent contract: take a handler map, merge+expand it in place, return it. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01RzzUgiebQ8ZhhgE2E7ZZU5

jaykay12 added 15 commits October 13, 2026 23:06

cl

7a77da0

changes

0db25b2

changes

79e159d

cl

da938cd

deeper tests

32ab27a

Merge branch 'main' into SOLR-16396-config-query

1d4a3e8

changes

49e6f13

tidy

35f7b3d

rebased with main

a05946a

queryparam

1efb602

minor

5baa8ab

corrections

6c10a14

minor fix

b02cf83

added cl

4e159cd

added tests

05d0a9b

github-actions Bot added tests cat:api labels Oct 16, 2026

cl minor

a7618b8

jaykay12 commented Oct 16, 2026

View reviewed changes

epugh requested changes Oct 16, 2026

View reviewed changes

changes

e6b2f07

github-actions Bot added the cat:cli label Oct 16, 2026

jaykay12 added 3 commits October 16, 2026 18:30

fix

061c966

fix for v1 consistency

13dd067

test fixes

1291fff

github-actions Bot added the documentation Improvements or additions to documentation label Oct 16, 2026

jaykay12 added 3 commits October 16, 2026 22:06

minor cleanup

3372ab7

todo

ba2c8a9

more tests coverage & strictness

e84d371

minor

6fede4c

jaykay12 requested a review from epugh October 16, 2026 17:51

jaykay12 mentioned this pull request Oct 16, 2026

SOLR-16396: Migrate remaining GET /config/{component} sections to JAX-RS #5174

Merged

7 of 8 tasks

epugh and others added 4 commits October 17, 2026 09:28

Merge branch 'main' into SOLR-16396-config-requestHandler

d444b97

tidying

c045334

epugh mentioned this pull request Oct 17, 2026

Fix v2 API 404 when a /config request is proxied to another node #5178

Merged

5 tasks done

epugh and others added 5 commits October 17, 2026 11:13

Merge branch 'fix-v2-proxy-collection-alias' into SOLR-16396-config-r…

1270dbf

…equestHandler

Merge branch 'main' into SOLR-16396-config-requestHandler

6f5d540

fixed packagetooltest

54d11e2

cl

dc40947

epugh and others added 4 commits October 20, 2026 07:06

Merge branch 'SOLR-16396-config-requestHandler' of https://github.com…

691e544

…/jaykay12/solr into pr/5168

Merge remote-tracking branch 'upstream/main' into pr/5168

cca9a44

# Conflicts: # solr/core/src/test/org/apache/solr/handler/admin/api/GetConfigSolrCloudTest.java

epugh added this to the 10.x milestone Oct 20, 2026

epugh merged commit 7e41990 into apache:main Oct 20, 2026
7 checks passed

epugh mentioned this pull request Oct 20, 2026

SOLR-16396: Align v2 full-config section keys with pluralised forms #5175

Merged

6 of 8 tasks

jaykay12 deleted the SOLR-16396-config-requestHandler branch October 20, 2026 19:56

Conversation

jaykay12 commented Oct 16, 2026

Description

Already landed / related:

Solution

Tests

Checklist

Uh oh!

jaykay12 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaykay12 Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jaykay12 commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing for requestHandler

Uh oh!

epugh left a comment

Choose a reason for hiding this comment

Uh oh!

epugh Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

jaykay12 Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epugh Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

jaykay12 Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

epugh Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

jaykay12 Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

jaykay12 Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

jaykay12 commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaykay12 commented Oct 19, 2026

Uh oh!

epugh commented Oct 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jaykay12 left a comment •

edited

Loading

jaykay12 Oct 16, 2026 •

edited

Loading

jaykay12 commented Oct 16, 2026 •

edited

Loading

jaykay12 Oct 16, 2026 •

edited

Loading

jaykay12 commented Oct 16, 2026 •

edited

Loading