Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
SOLR-1725 and other issues (recent changes to analysis factories and codecs) make it possible to plug in extensions like analyzer factories, codecs, scripting engines or TIKA parsers (TIKA extraction plugin!!!) as SPIs. The current problem (we solved this alreeady for codecs and analyzer factories with a classloader-reload hack: LUCENE-4259) is the following:
You have to unpack WAR file and repack with the missing JAR files. If you would do it the "solr way" and put those jars into the $SOLR_HOME/lib folder like plugins, they are not seen. The problem is that plugins loaded by solr are loaded using SolrResourceLoader's classloader (configureable via solrconfig.xml), but as this classloader is not also context classloader, SPI does not look into it, so scripting engines, TIKA plugins, (previously codecs) are not seen.
We should investigate how to manage setting the context classloader of all threads solr ever sees to point to our own solr classloader.
When we do this, I also suggest to only ship with TIKA core libs but not tika-parsers and the big dependency hell. TIKA parsers are also loaded via SPI, so user can download the TIKA parser distribution and drop into $SOLR_HOME/lib. By that a user can also use only those extraction plugins really needed. The current solr distribution only consists of mostly useless JAR files (for many users) for Solr Extraction handler. We dont need to ship with all of them, we can just tell the user how to "install" the needed SPIs. The same for analysis-extras (user only needs to copy morphologic JAR or smartchinese JAR into $SOLR_HOME/lib - this works already!!!). No need for the "hull contrib". Scripting engines is the same.
We should just ship with some scripts (ANT based) to download the JAR files into $SOLR_HOME.
Attachments
Issue Links
- is related to
-
-
- Closed
-