[ https://issues.apache.org/jira/browse/SOLR-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882198#comment-17882198 ]
David Smiley commented on SOLR-17256: ------------------------------------- Another approach would be for Http2SolrClient.withBaseUrl to take only the URL and _return_ a SolrClient that is scoped to that URL. Close would no-op; it'd hold no resources other than a reference back to the original Http2SolrClient. requestAsync should perhaps be a base method on SolrClient. > Remove SolrRequest.getBasePath setBasePath > ------------------------------------------ > > Key: SOLR-17256 > URL: https://issues.apache.org/jira/browse/SOLR-17256 > Project: Solr > Issue Type: Improvement > Components: SolrJ > Reporter: David Smiley > Priority: Minor > Labels: newdev, pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > SolrRequest has a getBasePath & setBasePath. The naming is poor; it's the > URL base to the Solr node like "http://localhost:8983/solr". It's only > recognized by HttpSolrClient; LBSolrClient (used by CloudSolrClient) ignores > it and will in fact mutate the passed in request to its liking, which is > rather ugly because it means a request cannot be used concurrently if the > user wants to. But moreover I think there's a conceptual discordance of > placing this concept on SolrRequest given that some clients want to route > requests to nodes *they* choose. I propose removing this from SolrRequest > and instead adding a method specific to HttpSolrClient. Almost all existing > usages of setBasePath immediately execute the request on an HttpSolrClient, > so should be easy to change. -- 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