[ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056201#comment-16056201
 ] 

Jason Gerlowski commented on SOLR-10915:
----------------------------------------

I think I'm reading you wrong.

bq. we should only have client constructors that accept the builder, and 
nothing else - even private constructors.

and

bq. We aren't 'removing' anything here but just deprecating so we should be fine

seem to conflict a little bit.  The first implies removing all constructors 
except the ones created by this patch.  The second (as I read it) says that we 
should be deprecating but not removing any constructors here.

I'm fine with either approach, just wanted to clarify before updating the 
patch.  Sorry for the confusion on my part.

> 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]

Reply via email to