[
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054432#comment-16054432
]
Anshum Gupta commented on SOLR-10915:
-------------------------------------
[~gerlowskija], ideally I'd want to build my extended client with something
like:
{code:java}
MyClient client = new
MyBuilder().withBaseSolrUrl("http://myBaseUrl/solr";).build();
{code}
but MyBuilder wouldn't have access to anything from the parent Builder class.
The constructor for the client would need the object and so we'd have a
deadlock.
I could just add a setter and get things taken care of there but I wouldn't be
able to do anything at construction time.
Also, adding everything to the client itself instead of through the builder
breaks how it should be extended in my opinion and shouldn't be recommended.
I haven't started working on this but I know what to do. If you want to take a
shot at it, go for it and I can review it and get this in.
> 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]
