It looks like <lib> directives are only used in solrconfig.xml to have jars loaded by collection-specifc classloaders.
Contribs/plugins that aren't used at the collection level need to have jars access by use of the "sharedLib" tag (that reads from -Dsolr.sharedLib) in most configs. So in my case I had to start Solr with "bin/solr start -c -Dsolr.sharedLib=../../dist/,../../contrib/gcs-repository/lib" Thanks to Hoss for setting me on the right track eventually. Jason On Thu, May 27, 2021 at 10:20 AM Jason Gerlowski <[email protected]> wrote: > > Hey all, > > SOLR-15090 recently added a contrib module that allows collection > backups to be stored and retrieved from Google Cloud Storage (GCS). > I'm working now on backporting that change to 8x > (https://github.com/apache/lucene-solr/pull/2501). I'm hitting a > classloading issue I didn't see on main/9x, and figured I'd ask about > it here. > > In short, taking a backup that uses the new GCS contrib results in a > ClassNotFoundException [1] on 8.x. An identical request with > identical solr.xml configuration [2] succeeds on main/9x. I've added > SolrResourceLoader logging that validates that the contrib JAR is > getting picked up by Solr. And I've inspected the contrib JAR file in > 'dist/' and verified that the class in question > ("org.apache.solr.gcs.GCSBackupRepository") is present there. > > So my best guess is that the contrib JAR is getting loaded but by a > different classloader than is used by the collection-admin APIs at > runtime to lookup the class. Is there some difference in the > classloader setup, or in the way <lib/> tags are handled between 8 and > 9? Does anyone have any other suggestions as to what might be going > on? > > Best, > > Jason > > [1] Stacktrace: https://paste.apache.org/om3y5 > [2] solr.xml: https://paste.apache.org/fslcz --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
