i have a minhash logic that uses guava 18.0 method that is not in guava
14.0.1. This minhash logic is a separate maven project. I'm including it in
my project via maven.the code is being used as a search component on the
set of results. The logic goes through the search results and deletes
duplicates. here is the solrconfig.xml

    <requestHandler name="/select" class="solr.SearchHandler" default="true"
>

       <arr name="last-components">

       <str>tvComponent</str>

       <str>terms</str>

       <str>minHashDedup</str>

       </arr>

    </requestHandler>

  <searchComponent name="minHashDedup" class="com.xyz.DedupSearchHits"><str
name="MAX_COMPARISONS">5</str>

DedupSearchHits class is the one implementing the minhash (hence using
guava 18). I start solr via the solr.in.sh script. The error I am getting
is:


Caused by: java.lang.NoSuchMethodError:
com.google.common.hash.HashFunction.hashUnencodedChars(Ljava/lang/CharSequence;)Lcom/google/common/hash/HashCode;

at com.xyz.incrementToken(MinHashTokenFilter.java:54)

at com.xyz.MinHash.calculate(MinHash.java:131)

at com.xyz.Algorithms.minhash.MinHasher.compare(MinHasher.java:89)

at com.xyz.Algorithms.minhash.DedupSearchHits.init(DedupSearchHits.java:74)

at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:619)

at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:2311)

at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:2305)

at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:2338)

at org.apache.solr.core.SolrCore.loadSearchComponents(SolrCore.java:1297)

at org.apache.solr.core.SolrCore.<init>(SolrCore.java:813)


What is the best design to solve this problem?I understand the point of
modularity but how can i include logic into solr that does result
processing without loading that jar into solr?

thank you


On Tue, May 26, 2015 at 8:00 AM, Daniel Collins <danwcoll...@gmail.com>
wrote:

> I guess this is one reason why the whole WAR approach is being removed!
> Solr should be a black-box that you talk to, and get responses from.  What
> it depends on and how it is deployed, should be irrelevant to you.
>
> If you are wanting to override the version of guava that Solr uses, then
> you'd have to rebuild Solr (can be done with maven) and manually update the
> pom.xml to use guava 18.0, but why would you? You need to test Solr
> completely (in case any guava bugs affect Solr), deal with any build issues
> that arise (if guava changes any APIs), and cause yourself a world of pain,
> for what gain?
>
>
> On 26 May 2015 at 11:29, Robust Links <pey...@robustlinks.com> wrote:
>
> > i have custom search components.
> >
> > On Tue, May 26, 2015 at 4:34 AM, Upayavira <u...@odoko.co.uk> wrote:
> >
> > > Why is your app tied that closely to Solr? I can understand if you are
> > > talking about SolrJ, but normal usage you use a different application
> in
> > > a different JVM from Solr.
> > >
> > > Upayavira
> > >
> > > On Tue, May 26, 2015, at 05:14 AM, Robust Links wrote:
> > > > I am stuck in Yet Another Jarmagedon of SOLR. this is a basic
> > question. i
> > > > noticed solr 5.0 is using guava 14.0.1. My app needs guava 18.0. What
> > is
> > > > the pattern to override a jar version uploaded into jetty?
> > > >
> > > > I am using maven, and solr is being started the old way
> > > >
> > > > java -jar start.jar
> > > > -Dsolr.solr.home=...
> > > > -Djetty.home=...
> > > >
> > > > I tried to edit jetty's start.config (then run java
> > > > -DSTART=/my/dir/start.config
> > > > -jar start.jar) but got no where...
> > > >
> > > > any help would be much appreciated
> > > >
> > > > Peyman
> > >
> >
>

Reply via email to