Re: YAJar
Maybe maven shade can help your situation ? https://maven.apache.org/plugins/maven-shade-plugin/ http://stackoverflow.com/questions/13620281/what-is-the-maven-shade-plugin-used-for-and-why-would-you-want-to-relocate-java Create a self-contained jar with guava package renamed. Not very pretty but it should work. On 5/25/15, 9:14 PM, 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
Re: YAJar
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
Re: YAJar
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
Re: YAJar
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
Re: YAJar
No, not really. Creating your own components that extend Solr is quite acceptable - they can live in the Solr Home lib directory outside of the war. But really, if you are coding within Solr, you really need to use the libraries that Solr uses. Or... create a JIRA ticket and help to upgrade Solr to the next version of the library you need. Or explain here what you are trying to so folks can help you find another way to achieve the same. Upayavira On Tue, May 26, 2015, at 01:00 PM, Daniel Collins 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
Re: YAJar
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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
What I am suggesting is that you set up a stand alone version of solr with 14.0.1 and run some sort of test suite similar to what you would normally use solr for in your app. The replace the guava jar and re-run the tests. If all works well, and I suspect it will because it did for me, then you can use 18.0. Simple really. François On May 26, 2015, at 10:30 AM, Robust Links pey...@robustlinks.com wrote: 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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
I'm not aware of a way you can do this, other than upgrading the Guava in Solr itself. Or rather, you'd need to create your own classloader and load your own instance of Guava using that rather than the default classloader. That's possible, but would be rather ugly and complex. I'd say research what's required to upgrade the Guava in Solr. Upayavira On Tue, May 26, 2015, at 03:11 PM, Robust Links 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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
Re: YAJar
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 strtvComponent/str strterms/str strminHashDedup/str /arr /requestHandler searchComponent name=minHashDedup class=com.xyz.DedupSearchHitsstr name=MAX_COMPARISONS5/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
YAJar
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
