[
https://issues.apache.org/jira/browse/SOLR-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17044:
----------------------------------
Labels: pull-request-available (was: )
> Improve API path specifying in SolrJ
> ------------------------------------
>
> Key: SOLR-17044
> URL: https://issues.apache.org/jira/browse/SOLR-17044
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ, v2 API
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, URL-driven SolrClients receive a URL that typically ends in
> "/solr". Requiring users to specify this context-root in their URLs has made
> sense historically, since all v1 paths start with "/solr". But this has
> become limiting as Solr's v2 APIs (which use the "/api" context root) become
> more mature.
> SolrJ has some string manipulation in a few spots to try to accomodate this,
> but it's patchy and relatively brittle (relying on overly specific
> 'instanceof' checks, etc.). We should come up with a more reliable way to
> ensure that SolrClient's can make both v1 and v2 requests.
> Here's one idea for how we could approach this:
> # Create a new SolrRequest method to specify the initial path segment (i.e.
> /solr vs /api) on a per-request basis. We could either do this directly
> (e.g. "getRootPath()"), or indirectly (e.g. "isV2()").
> # Modify SolrClients to consider both the new method and the existing
> "getPath" when sending requests.
> # Add logic to SolrJ to strip "/solr" from any provided base URLs, and
> document that SolrClient URLs no longer require the "/solr" context-root
> suffix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
