: 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
