[
https://issues.apache.org/jira/browse/SOLR-14902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203216#comment-17203216
]
David Smiley commented on SOLR-14902:
-------------------------------------
The SSL hack was added in SOLR-10783; I added a comment on that issue pointing
here.
Proposal:
* What goes in WEB-INF/lib would instead go to a new lib dir /server/lib/solr.
Need to tell Jetty about that dir in bin/solr.
* in solr-jetty-context.xml, set {{<Set
name="parentLoaderPriority">true</Set>}}. Not sure if this is needed.
* in solr-jetty-context.xml, expose SolrDispatchFilter from the server's
classpath to the web context. Libs at the Jetty level are invisible to Solr,
with some exceptions that can be controlled.
https://www.eclipse.org/jetty/documentation/current/jetty-classloading.html#configuring-webapp-classloading
CC [~uschindler] I suspect you have thoughts on this since you've proposed
replacing much of the Jetty/Solr bootstrapping with a single source file. That
would be the epitome of hard-coding -- we'd lose the rather nice text file
configuration that's possible today. One example is adding CORS, which is
rather common and can be done easily without code changes.
> Merge Jetty and Solr classpath
> ------------------------------
>
> Key: SOLR-14902
> URL: https://issues.apache.org/jira/browse/SOLR-14902
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
>
> The standard webapp/server classpath separation is pointless for Solr. The
> separation is abused/broken when SSL is configured (see bin/solr
> WEB-INF/lib/* hack addition to Jetty's classpath).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
