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
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Reply via email to