You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Jan Høydahl <ja...@cominvent.com> on 2020/02/19 21:29:07 UTC

Re: [jira] [Commented] (SOLR-599) Lightweight SolrJ client

It would be cleanest to avoid compile time deps in solrj-core and have a separate ZkCloudSolrClient in solr-zk.

But perhaps easier sort term to just slice it up in the packaging stage when creating pom, and accept ClassNotFound unless you also add solrj-zk to path... I’m not enough into the solrj module to know how easy it is to carve out parts of it..

Jan Høydahl

> 19. feb. 2020 kl. 20:21 skrev Gus Heck (Jira) <ji...@apache.org>:
> 
> 
>    [ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040356#comment-17040356 ] 
> 
> Gus Heck commented on SOLR-599:
> -------------------------------
> 
> Do those HTTP API's have a way to proactively advise the client of changes to aliases, available nodes etc? or do they require/conduct polling? Isn't one of the primary reasons we have zk because it allows the client to watch for changes? I've been meaning to look into this but keep getting distracted by other things so I better just mention it :). I remember having some difficulty with the http providers when the tests randomly selected them while I was working on TRAs, but they may have improved since then.
> 
>> Lightweight SolrJ client
>> ------------------------
>> 
>>                Key: SOLR-599
>>                URL: https://issues.apache.org/jira/browse/SOLR-599
>>            Project: Solr
>>         Issue Type: Improvement
>>         Components: clients - java, SolrJ
>>           Reporter: Shalin Shekhar Mangar
>>           Priority: Minor
>>            Fix For: 4.9, 6.0
>> 
>>        Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, SOLR-599.patch
>> 
>> 
>> SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils.
>> This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr.
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
> For additional commands, e-mail: issues-help@lucene.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org