SOLR-16396 | Migrate GET config sections updateHandler, directoryFactory, indexConfig, and codecFactory to JAX-RS.

[jaykay12]

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

Description

Part of SOLR-16396 (Config GET → JAX-RS)

This PR: migrate the five same-shape section GETs to JAX-RS:

• GET /config/query
• GET /config/updateHandler
• GET /config/directoryFactory
• GET /config/indexConfig
• GET /config/codecFactory

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

Solution

• Add ConfigApi.Get#getConfigComponent with an allow-listed @path regex for those five names & reused ConfigInfoResponse.

• Implement on GetConfig: convert SolrConfig, slice one section, wrap with NullKeyTolerantMap (shared solrConfigAsMap / jsonSafeCopy with full getConfig). Do not run implicit-handler / expandParams logic — those sections never had it.

• V1 SolrConfigHandler.handleGET squashes these five through the same Jersey method (MIGRATED_CONFIG_COMPONENTS). Other sections stay on the legacy branch.

• Leave AnnotatedApi GET /config/{component} in place for unmigrated names.

• TODOs: keep the path regex in sync with the Set; drop the Set when remaining sections migrate.

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

Tests

• GetConfigTest / GetConfigSolrCloudTest: SolrJ GetConfigComponent for each
  migrated section; assert single-key config map.
• Existing v1 TestSolrConfigHandler paths (e.g. /config/updateHandler) continue
  to exercise squash.

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 ✅

[jaykay12]

Testing for codecFactory

type	main branch	feature branch
v1 api
-	-	-
v2 api

[jaykay12]

Testing for indexConfig

type	main branch	feature branch
v1 api
-	-	-
v2 api

v1 API gives 404 for /indexConfig in production as well, its missing in the subpath registration done in SolrConfigHandler, @epugh lmk if we should fix it? I will create jira for it & raise minor fix PR for the same.

since, v2 is the new future & it works there, so not raising any PR before confirmation. that 404 behaviour remains the same in this PR right now.

[jaykay12]

Testing for directoryFactory

type	main branch	feature branch
v1 api
-	-	-
v2 api

[jaykay12]

Testing for updateHandler

type	main branch	feature branch
v1 api
-	-	-
v2 api

[jaykay12]

Testing for query

type	main branch	feature branch
v1 api
-	-	-
v2 api

Update

Encountered cases like:
http://localhost:8983/solr/techproducts/config/query?componentName=filterCache&meta=true
http://localhost:8983/api/collections/techproducts/config/query?componentName=filterCache&meta=true

which i came to know via failing test in TestPackages

query would be migrated to V2 alongside others of its own type.

Moving out query from this PR scope for now.

[jaykay12]

self review ✅
local testing ✅
precommit passes ✅

@epugh can you please review & run workflow triggers on this?

[epugh]

interesting! I mean, why not...

[epugh]

LGTM. tested locallyl