[ https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Gerlowski updated SOLR-10915: ----------------------------------- Attachment: SOLR-10915.patch Updated patch. The only constructor I was able to remove outright was a private one in CloudSolrClient. The others have been deprecated, with their implementations changed to call out to the Builder-based ctor. All tests pass. > Make SolrClient classes extendable without code duplication > ----------------------------------------------------------- > > Key: SOLR-10915 > URL: https://issues.apache.org/jira/browse/SOLR-10915 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - java > Reporter: Anshum Gupta > Assignee: Anshum Gupta > Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10915.patch, SOLR-10915.patch.with-deprecations, > SOLR-10915.patch.without-deprecations > > > SolrClient used to be easily extendable but our move to Builder pattern has > made it impossible to extend those classes without code duplication. > As an example, if we wanted to extend HttpSolrClient we would also want to > extend the Builder. The problem is that the constructor of the main class, > does not accept the builder object but explicit parameters, and the inherited > class doesn't have access to any of those values from the Builder object as > they are all private. > Generally, we'd want to have the client object constructor accept the > Builder, instead of explicit values, and also make the Builder values > protected so the inherited classes could use them. > I'm marking this as a blocker for 7.0 as this is an important piece that > needs to be fixed before the major release, specially now that we know that > this problem exists. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org