i can't run 14.0.1. that is the problem. 14 does not have the interfaces i need
On Tue, May 26, 2015 at 10:28 AM, François Schiettecatte < fschietteca...@gmail.com> wrote: > Run whatever tests you want with 14.0.1, replace it with 18.0, rerun the > tests and compare. > > François > > > On May 26, 2015, at 10:25 AM, Robust Links <pey...@robustlinks.com> > wrote: > > > > by "dumping" you mean recompiling solr with guava 18? > > > > On Tue, May 26, 2015 at 10:22 AM, François Schiettecatte < > > fschietteca...@gmail.com> wrote: > > > >> Have you tried dumping guava 14.0.1 and using 18.0 with Solr? I did a > >> while ago and it worked fine for me. > >> > >> François > >> > >>> On May 26, 2015, at 10:11 AM, Robust Links <pey...@robustlinks.com> > >> wrote: > >>> > >>> 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 > >>>>>> > >>>>> > >>>> > >> > >> > >
