[ https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056210#comment-16056210 ]
Anshum Gupta commented on SOLR-10915: ------------------------------------- Sorry about that confusion, should've read what I wrote :). I do intend to have only constructors that accept a builder object. Everything else that has never been released i.e. was added after the last release OR is private can be completely removed, and constructors that are protected/public should be marked as deprecated. Does this make sense? > 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.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