[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-dev
Subject:    Re: [jira] [Commented] (SOLR-599) Lightweight SolrJ client
From:       Jan_Høydahl <jan.asf () cominvent ! com>
Date:       2020-02-19 21:29:07
Message-ID: BEEB8EA4-F6A6-477B-805E-7A00DA8B861E () cominvent ! com
[Download RAW message or body]

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) <jira@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


[prev in list] [next in list] [prev in thread] [next in thread]