[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814783#comment-17814783
]
Jason Gerlowski commented on SOLR-17066:
----------------------------------------
Alright - I think I've got this sorted out. To summarize the gitbot comments
above: I reverted from both 'main' and 'branch_9x' Saturday night, restored to
'main' on Monday, and restored to 'branch_9x' Tuesday morning.
The bug is this bit of code in URLUtil.java, which this ticket was relying on
in several places in an attempt to identify and then split core URLs into their
constituent pieces:
{code}
public static boolean isBaseUrl(String url) {
final var normalizedUrl = removeTrailingSlashIfPresent(url);
return normalizedUrl.endsWith("/solr");
}
{code}
This code is correct in 'main', but incorrect in branch_9x where users can
specify an arbitrary "hostContext" instead of "/solr". I've fixed this on
branch_9x by omitting the identify-and split-core-URLs logic entirely,
replacing it instead with what I hope is thorough javadocs clarifying that (1)
use of core URLs is deprecated and slated to be removed in 10.0, and (2) core
URLs are mutually exclusive with the "withDefaultCollection" builder option.
I've run the tests several times on branch_9x without hitting any failures, but
if anyone notices this causing problems again please let me know!
> 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
