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

Mikhail Khludnev commented on SOLR-10915:
-----------------------------------------

I want to commit on top of 
{code}
commit e43253312f965ba838d80c2000dee761df1f25f5
Author: Uwe Schindler <[email protected]>
Date:   Sat Jun 24 15:35:00 2017 +0200
{code}
and having precommit errors 
{quote}
common.compile-test:
    [javac] Compiling 3 source files to 
/home/[email protected]/lucene-solr/solr/build/solr-solrj/classes/test
    [javac] 
/home/[email protected]/lucene-solr/solr/solrj/src/test/org/apache/solr/client/solrj/embedded/SolrExampleStreamingTest.java:143:
 error: non-static variable this cannot be referenced from a static context
    [javac]         return new ErrorTrackingConcurrentUpdateSolrClient(this);
    [javac]                ^
{qoute}
is ok to push anyway? 
  

> 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, SOLR-10915.patch, 
> 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