+1 Sounds great Gus! I do wonder what the relationship will be between Jersey's comparable framework as we migrate to that within Solr. It's still rather theoretical since V2 remains distant. In particular, I suspect authorization matters will likely need a closer integration to Solr's internals to be applied at the point of internal dispatch -- something I expect a Jersey interceptor thing should do, but a ServletFilter comes before then. So everything you listed makes sense to me except the authorization aspect. Authentication can come early.
While you've started this thread, I want to add that I plan to convert SolrDispatchFilter to be SolrServlet. Once the pass-through option is removed (I have WIP for this), I don't think there's anything stopping it. "Dispatch" is no longer the right characterization of it; dispatch happens in HttpSolrCall. That thing is a bit of a mess, sadly. On Sat, Jan 10, 2026 at 11:40 AM Gus Heck <[email protected]> wrote: > Hi Folks, > > I would like to improve the structure of our code to enable easier > maintenance, better readability, better extensibility and better > customizability for power users. I believe one step in the right direction > is to embrace the use of multiple ServletFilters such that elements of > setup and teardown for request processing are segregated into distinct, > focused classes. I had talked with many individuals about it and espoused > this opinion on the list several times with no significant opposition and > some encouragement so, with some time to spare over the holidays I filed a > ticket, created tasks. Feedback on review indicated that there was a > feeling this needed (further, formal) discussion on the list, so here it > is. > > The ticket I filed is https://issues.apache.org/jira/browse/SOLR-18040 > > - Overall this change should be transparent to most users > - I expect this change to make it MUCH easier to identify the various > independent "housekeeping" (non-search) tasks required to handle > requests > such as: > - Excluding some paths to enable UI files without auth > - Setting some request attributes, > - Rate Limiting > - Initialization/completion of tracing > - Initialization/completion of auditing > - Authentication/Authorization (later task to handle those > separately) > - Post request cleanup of SolrRequestInfo, fully consuming requests, > deleting multi-part request temp files, etc. > - Power users seeking to optimize solr, or with special needs wrt > auth/audit/tracing/rate-limiting would be able to replace or eliminate > these aspects. > - Addition of new request handling features can easily be slotted in > between existing features (either by folks contributing to the project, > or > power users customizing Solr). > - If well named, the list of filters in web.xml will serve as high level > self documenting code, revealing the types of and order of the initial > request processing. > > The only opposition I have ever heard previously is the relatively > vague notion that someday we might want to get rid of Jetty entirely. Such > a change has been mentioned ever since we stopped packaging Solr as a .war > file. And while, in theory, it could provide optimization of request > processing, it strikes me both as something nobody is prepared to do any > time soon, and as something that runs a huge risk of re-inventing a lot of > wheels for little gain. > > On the other hand, leaning into Servlet filters can be done now, quickly > and if we ever "dump" jetty it will directly translate to a set of request > decorators we will need anyway. > > I expected that the coding effort for this would be just a few days and so > far that has not been contradicted yet, though the need to wait for review > on every single step, and the fact that Crave has not been picking up PR > build requests for multiple hours has significantly extended the wall > clock. I'm having some thoughts on how we can mitigate this tension between > small changes and molasses-like progression, however that's a separate > discussion. > > If you have thoughts for or against this direction please speak up now. > > -Gus > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
