[
https://issues.apache.org/jira/browse/SOLR-17883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski reassigned SOLR-17883:
--------------------------------------
Assignee: Jason Gerlowski
> "bin/solr" tools should have more expansive classpath
> -----------------------------------------------------
>
> Key: SOLR-17883
> URL: https://issues.apache.org/jira/browse/SOLR-17883
> Project: Solr
> Issue Type: Improvement
> Components: SolrCLI
> Affects Versions: 9.9
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The ref-guide singles out {{<solr_install>/lib}} as being a particularly good
> place to put plugin jars during Dockerfile packaging:
> bq. The .jar files placed here are available to all Solr cores running on the
> node, and to node level plugins referenced in solr.xml — so basically
> everything. Contrary to <solr_home>/lib/, this directory is always located in
> the install dir, so it can be used e.g. for custom Dockerfile to place custom
> plugin jars.
> But this comes with a bit of a hidden catch: the directory is on the
> classpath of Solr server, but it's *not* on the classpath for "bin/solr"
> tools more generally. There may be other cases, but I've seen this cause
> issues with "bin/solr zk" in particular, where users may want to use their
> own ZkAclProvider or ZkCredProvider implementations with "bin/solr zk".
> We should add {{<solr_install>/lib}} to the tool classpath, or update the
> ref-guide with other guidance on where jars can be placed to be loadable by
> the bin/solr tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
