[
https://issues.apache.org/jira/browse/SOLR-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13429653#comment-13429653
]
Lance Norskog commented on SOLR-3716:
-------------------------------------
Thanks for flushing out another problem in how classpaths work.
I have a small question: how would I add a Java SecurityManager class into this
mix? I would like to set a security manager object for each core that governs
the activities of code in that core: loading a 3-megabyte synonym file, loading
a jar file that calls out to the DHS, whatever. (Why? A hosted Solr business is
a lot easier if you can run someone's collection configs in a sandbox.)
> Make SolrResourceLoaders ClassLoader available as context class loader
> ----------------------------------------------------------------------
>
> Key: SOLR-3716
> URL: https://issues.apache.org/jira/browse/SOLR-3716
> Project: Solr
> Issue Type: Bug
> Components: scripts and tools
> Reporter: Uwe Schindler
> Fix For: 4.0, 5.0
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
