[DISCUSS] Breaking out multiple filters from SolrDispatchFilter

[Gus Heck <gu...@gmail.com>]

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)

Re: [DISCUSS] Breaking out multiple filters from SolrDispatchFilter

[David Smiley <ds...@apache.org>]

And SolrDispatchFilter becomes SolrServlet:
https://issues.apache.org/jira/browse/SOLR-18112
https://github.com/apache/solr/pull/4119

On a related note, I think JettySolrRunner shouldn't sort of pretend to
host the admin UI.  I seriously doubt it works but nonetheless it
registers PathExclusionFilter and forgot LoadAdminUiServlet, and adds a
default servlet.  If we want to actually test the admin UI integration into
Solr, lets use BATS or Docker, and thus actually test Solr realistically.
Neither of those options existed when JettySolrRunner was written.  JSR
should be simpler (without them).

Re: [DISCUSS] Breaking out multiple filters from SolrDispatchFilter

[Gus Heck <gu...@gmail.com>]

On Mon, Jan 12, 2026 at 9:53 AM David Smiley <ds...@apache.org> wrote:

> 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.
>

In this effort, I would only intend to move existing code to a filter,
there are overall plugability questions for authentication, but that would
be a whole other endeavor.

I'm targeting resuming my work next weekend unless there's opposition.

Re: [DISCUSS] Breaking out multiple filters from SolrDispatchFilter

[David Smiley <ds...@apache.org>]

+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 <gu...@gmail.com> 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)
>