[
https://issues.apache.org/jira/browse/SOLR-18040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048269#comment-18048269
]
David Smiley commented on SOLR-18040:
-------------------------------------
Looking forward to seeing well structured layering here :-)
A positive outcome is that these request processing matters will clearly be
seen in web.xml which surfaces architecturally what's going on in the
configuration. And it will make these filters disable-able or replaceable for
those customizing Solr. Very nice. It reinforces Solr's strength of
configurability.
I noticed that the Jersey framework, that we use for the new V2, has extensive
filters/interceptors. If we eventually get through seeing V2 API through, I
assume we'll dispatch 100% via Jersey. For some matters like authorization, I
suspect it makes the most sense to handle that at a Jersey level and not a
Servlet filter level since at the Jersey level we have access to the handler
and it's annotations. CC [~gerlowskija]
> Pull various logic that wraps our requests into their own servlet filter
> ------------------------------------------------------------------------
>
> Key: SOLR-18040
> URL: https://issues.apache.org/jira/browse/SOLR-18040
> Project: Solr
> Issue Type: Improvement
> Reporter: Gus Heck
> Priority: Major
>
> There are a number of things in SolrDispatchFilter that have the essential
> pattern:
> * doStuff
> * proceed with request
> * undoStuff (some cases)
> This is the exact pattern that servlet filters are meant to handle, and the
> servlet specification guarantees a predictable execution order based on
> position in web.xml. We should work towards removing prepatory and teardown
> logic from SolrDispatchFilter such that it only handles dispatch, and not
> things like:
> * Excluding paths for static resources
> * Tracing
> * Authentication/Authorization
> * Circuit breakers
> * Close shielding
> * SolrRequestInfo
> * etc
> This will be the parent ticket for discussing what should and shouldn't be
> pulled out and each thing we pull out can be a sub-task. Once each of these
> things is separated then the logic wrapping the request will be easy to find,
> and we can be sure that the finishing logic isn't going to get skipped.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
