[
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054373#comment-16054373
]
Jason Gerlowski commented on SOLR-10915:
----------------------------------------
Yes, this is true. Most (see below) of the SolrClient implementations have
their constructors at protected visibility, so this is less of a problem with
extending the SolrClients and more of a problem of being able to re-use the
Builder code/pattern when you do so? (I ask this not in an attempt to minimize
the issue, but purely for clarification).
(Related to this issue in my mind is the fact that CloudSolrClient *doesn't*
have a protected constructor. This was raised on the mailing list, and a patch
was put forward in SOLR-9535 . Might be a good time to give that a little
attention too, though it's not as important as the concerns you raise in this
JIRA)
Getting back to this issue, I plan to push a patch for this tonight, unless
you've already started on it [~anshumg]?
> 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
> Priority: Blocker
> Fix For: master (7.0)
>
>
> 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]
