Skip to content

SOLR-16396: Migrate GET /config/requestHandler to JAX-RS - #5168

Open
jaykay12 wants to merge 22 commits into
apache:mainfrom
jaykay12:SOLR-16396-config-requestHandler
Open

jaykay12 wants to merge 22 commits into
apache:mainfrom
jaykay12:SOLR-16396-config-requestHandler

Conversation

@jaykay12

Copy link
Copy Markdown
Contributor

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

Description

Migrate GET /config/requestHandler to JAX-RS

Already landed / related:

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 jaykay12 left a comment •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +80 to +82
@QueryParam("componentName")
@Parameter(description = "Name of the specific request handler")
String component,

@jaykay12 jaykay12 Oct 16, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Screenshot 2026-10-16 at 1 30 49 AM

Comment thread solr/api/src/java/org/apache/solr/client/api/endpoint/ConfigApi.java Outdated
Comment thread solr/core/src/java/org/apache/solr/handler/admin/api/GetConfig.java
Comment thread solr/core/src/java/org/apache/solr/handler/admin/api/GetConfig.java
Comment thread solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java
@jaykay12

jaykay12 commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor Author

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 Screenshot 2026-10-16 at 4 49 03 PM Screenshot 2026-10-16 at 9 30 42 PM
- - -
v2 api - all Screenshot 2026-10-16 at 4 49 56 PM Screenshot 2026-10-16 at 9 31 48 PM
- - -
v1 api - filtered Screenshot 2026-10-16 at 4 52 55 PM Screenshot 2026-10-16 at 9 32 30 PM
- - -
v2 api - filtered Screenshot 2026-10-16 at 4 53 02 PM Screenshot 2026-10-16 at 9 32 38 PM
- - -
v1 api - filtered & expandParams Screenshot 2026-10-16 at 4 53 20 PM Screenshot 2026-10-16 at 9 35 46 PM
- - -
v2 api - filtered & expandParams Screenshot 2026-10-16 at 4 53 29 PM Screenshot 2026-10-16 at 9 36 01 PM

@epugh epugh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

int expectedParamsVersion);

@GET
@Path("/requestHandler")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jaykay12 jaykay12 Oct 16, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

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


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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does @StoreApiParameters mean?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Screenshot 2026-10-16 at 10 42 15 PM

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

jaykay12 commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor Author

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 and others added 3 commits October 17, 2026 19:11
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RzzUgiebQ8ZhhgE2E7ZZU5
epugh and others added 2 commits October 17, 2026 11:13
CI builds with -Werror, and errorprone flags comparing JettySolrRunner
instances with != instead of .equals().

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RzzUgiebQ8ZhhgE2E7ZZU5
@jaykay12

jaykay12 commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor Author

@epugh maybe we are having more issues than just this one, I can see that PackageToolTest still fails even after i merged your fix PR on top of this.


one suggestion - can i take this PR scope as migration to JAX-RS with requestHandler to requestHandler, pluralising of this end point, I can take up in a follow-up PR? that will actually help us divide & conquer the issue.

which means that - #5168 (comment) gets addressed in the follow-up PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cat:api cat:cli documentation Improvements or additions to documentation tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants