[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814775#comment-17814775
]
ASF subversion and git services commented on SOLR-17066:
--------------------------------------------------------
Commit 901a3099c93953e7be333b2d5fd15b92d5ed2966 in solr's branch
refs/heads/branch_9x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=901a3099c93 ]
Reinstate "SOLR-17066: Switch HttpSolrClient away from coreURLs, pt 2 (#2231)""
This commit fixes a bug in a previously committed (and then reverted)
change e8ac06.
The root of the problem lies in how Solr handles context-roots. Solr 9
allows configurable and arbitrary context roots, while Solr 10 disallows
this practice.
This difference wasn't accounted for when backporting the core URL
removal to branch_9x, causing a large number of test failures due to
some assumptions around what a path should look like. These assumptions
were valid for Solr 10 (i.e. `main`) but invalid for Solr 9.
In order to reinstate this commit on branch_9x, the commit no longer
inspects and splits user-provided URLs when creating clients. Instead,
it relies on thorough javadocs to clarify that use of core URLs is
(1) deprecated, and (2) mutually exclusive with the
`withDefaultCollection` builder option.
> Deprecate and remove core URLs in HttpSolrClient and friends
> ------------------------------------------------------------
>
> Key: SOLR-17066
> URL: https://issues.apache.org/jira/browse/SOLR-17066
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Jason Gerlowski
> Priority: Major
> Time Spent: 9h 20m
> Remaining Estimate: 0h
>
> Currently, URL-driven SolrClients can consume a base URL that either ends in
> an API-version specific path ("/solr" for v1 APIs, "/api" for v2), or in the
> full path to a specific core or collection ("/solr/techproducts").
> The latter option causes a number of problems in practice. It prevents the
> client from being used for any "admin" requests or for requests to other
> cores or collections. (Short of running a regex on
> {{SolrClient.getBaseURL}}, it's hard to even tell which of these restrictions
> a given client might have.) And lastly, specifying such core/collection URL
> makes it tough mix and match v1 and v2 API requests within the same client
> (see SOLR-17044).
> We should give SolrJ users some similar way to default collection/cores
> without any of these downsides. One approach would be to extend the
> {{withDefaultCollection}} pattern currently established in
> {{CloudHttp2SolrClient.Builder}}.
> (IMO we should also revisit the division of responsibilities between
> SolrClient and SolrRequest implementations - maybe clients shouldn't,
> directly at least, be holding on to request-specific settings like the
> core/collection at all. But that's a much larger concern that we might not
> want to wade into here. See SOLR-10466 for more on this topic.)
--
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
