You shouldn't have to package everything up. You say you've tried putting the jars in several different places. Do you have multiple jars for azure still lying around? I wonder if you might be seeing something truly wonky with the same jar being accessed in two places.
The output is numbing, but look at solr.log just after startup. It will list out all the directories it knows about. Then I'd look at the jars in each of those directories to see if there are duplicates and/or if the expected jars are in them. Not a great deal of help, but "jar hell" is ugly. Best, Erick On Thu, Dec 29, 2016 at 12:49 PM, Vinay B, <vybe3...@gmail.com> wrote: > Thanks, > > I think I already tried that approach > > ie. my solr config included the lib directive > > <lib dir="../contrib/updatehandler/lib" regex=".*\.jar" /> > > and i placed the azure jar in the same "lib" directory as the custom > updatehandler (../contrib/updatehandler/lib) so I expect the rather liberal > wildcard regex would pick it up. > > > > On Thu, Dec 29, 2016 at 12:51 PM, Emir Arnautovic < > emir.arnauto...@sematext.com> wrote: > >> Hi Vinay, >> >> You need to include libs using lib directives in Solr config: >> https://cwiki.apache.org/confluence/display/solr/Lib+Directi >> ves+in+SolrConfig. >> >> Regrads, >> Emir >> >> >> >> On 29.12.2016 19:11, Vinay B, wrote: >> >>> I'm modifying out custom update handler and the modifications needs access >>> to a third party jar (microsoft azure). >>> >>> For what it's worth, I use mvn as my build / packaging tool. >>> >>> During runtime, I've been encountering class not found errors in the >>> plugin >>> related to the azure library. >>> >>> 1. Is there something / some special place to place the azure jars so the >>> PLUGIN can access the azure classes? I tried putting the azure jar in the >>> tomcat/lib , WEB_INF/lib and also beside the plugin jar in the >>> updatehandler/lib directory . Just to be clear, the update handler itself >>> works fine. It's just the enhancements to support azure that result in >>> class not found errors >>> >>> 2. I managed to make things work by including all dependencies but that >>> has >>> bloated the plugin size significantly to over 70 MB. Is this the only way? >>> >>> See an example of this approach at >>> https://leifproblems.wordpress.com/2015/04/16/loading-a- >>> solr-plugin-with-all-maven-dependencies/ >>> >>> >> -- >> Monitoring * Alerting * Anomaly Detection * Centralized Log Management >> Solr & Elasticsearch Support * http://sematext.com/ >> >>