I don't mind Solr being a "webapp" in Jetty. I don't recall it constraining us or being interfering. Jetty is very customizable so we can tweak the Jetty-Solr relationship to our liking. A webapp makes it straightforward (no code!) for other users to add a CORS Filter in Solr or to add another webapp if they like.
On Fri, Nov 22, 2024 at 1:30 PM Chris Hostetter <hoss...@apache.org> wrote: > > : I suspect the choice of a ServletFilter vs Servlet was done for reasons > : that might have made sense forever-ago. It has always been weird. Does > it > : still make sense? Maybe Hossman remembers. > > Once upon a time (before solr even supported multi-core) there was a > SolrServlet bound to /select and a SolrUpdateServlet bound to /update, > while the admin UI was handled by JSPs (that were > directly accessible via their file names: schema.jsp etc..) > > You could use different request handlers via the 'qt' param on /select > requests, but there was no way to customize the handling of /update > requests. > > SOLR-104 introduced the "SolrDispatchFilter" -- bound to "/*" -- and the > ability to configure (and use) request handlers by path (for both search > and updates) > > The reason it was a "Filter" was so it could ignore any path that was > *NOT* a registered request handler and pass it down the chain -- this was > important not only for the Admin UI JSP pages, but for things like legacy > requests to "/update" to get the deprecated SolrUpdateServlet if the users > config didn't define an "/update" request handler. > > (This was also back in the day when "customizing the solr webapp" was not > only supported it was encouraged, so the passthrough behavior was > important for other reasosn as well) > > > Frankly, at this point, i'm not sure why it matters or makes sense to > worry about wether it's a dispatch filter or a servlet -- if the concern > is the logging or error handling just rip out the passthough behavior and > put whatever new behavior you want in the SolrDispatchFilter and avoid > the complexity of the rename. > > If we really want to overhaul the SolrDispatchFilter, let's go whole > hog, rip out all the servlet APIs and stop being a webapp :) > > > > -Hoss > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
