[
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056564#comment-16056564
]
Anshum Gupta commented on SOLR-10915:
-------------------------------------
There's existing constructors that were released in 6.6, which need to be
handled and either removed, or deprecated with our move to the single format
constructor for SolrClients.
[~gerlowskija], [~elyograg], and I had a discussion on irc and decided that we
shouldn't be going crazy with the code removal, and instead should just happily
deprecate stuff. It does mean working around with the current code and leaving
it unclean but considering this is publicly released code, it doesn't make
sense to just remove it.
Here's the approach that Jason suggested, which I think makes sense to handle
existing constructors. This routes everything through the new Builder
implementation.
{code:java}
public HttpSolrClient(String url, ResponseParser parser, Foo foo, Bar bar) {
final HttpSolrClient.Builder builder = new
HttpSolrClient.Builder(url).withResponseParser(parser).withFoo(foo)...;
this(builder);
}
public HttpSolrClient(Builder builder) {
/* actual constructor implementation/logic */
}
{code}
> 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]
