Repository navigation
Conversation
| @QueryParam("componentName") | ||
| @Parameter(description = "Name of the specific request handler") | ||
| String component, |
epugh
left a comment
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
doiuble check sheet, but I think this is now plural? "requestHandlers"????
There was a problem hiding this comment.
done.
V2 is @path("/requestHandlers") (plural), matching the sheet.
V1 stays singular requestHandler.
|
|
||
| @GET | ||
| @Path("/requestHandler") | ||
| @StoreApiParameters |
There was a problem hiding this comment.
what does @StoreApiParameters mean?
| summary = "Fetch request handlers (including implicit handler)", | ||
| tags = {"config"}) | ||
| ConfigInfoResponse getRequestHandler( | ||
| @QueryParam("componentName") |
There was a problem hiding this comment.
i think this is now a path param as well....
There was a problem hiding this comment.
Stated the reasoning here in my self-review: #5168 (comment)
There was a problem hiding this 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
|
Thanks @epugh for the quick review! I have addressed the comments. 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. |
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
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
|
@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. |














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:
mainbranch../gradlew check.