[
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.with-deprecations
SOLR-10915.patch.without-deprecations
I made the changes pretty much exactly as you requested above Anshum.
One question I had when making the changes was whether we also wanted to
deprecate the existing constructors and remove any uses of them. You didn't
explicitly call for that in the issue description, but since one of the main
goals of the builders was to cut down on constructor duplication/sprawl, it
would make sense.
Anyway, I've uploaded two patches, one that leaves the existing constructors
as-is, and another that deprecates the existing ctors and changes any calls to
go to the builder-based constructor.
Both pass tests on {{master}}.
> 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: [email protected]
For additional commands, e-mail: [email protected]
