-
Notifications
You must be signed in to change notification settings - Fork 791
SOLR-18041 PathExclusionFilter extracted from SolrDispatchFilter #3981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
dsmiley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed in JettySolrRunner?
If tests pass then cool.
| Matcher matcher = p.matcher(requestPath); | ||
| if (matcher.lookingAt()) { | ||
| if (chain != null) { | ||
| chain.doFilter(request, response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow that was a sneaky side-effect of what looked like a simple boolean method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup took me a moment to figure out why my first pass attempt was somehow still passing control to SolrDispatchFilter (which becomes next in line)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah actually looking there, there is a change that probably should be made, since patterns are being set (but now ignored).
| // servlets that are more focused in scope. This should become possible now that we have a | ||
| // ServletContextListener for startup/shutdown of CoreContainer that sets up a service from which | ||
| // things like CoreContainer can be requested. (or better yet injected) | ||
| public class SolrDispatchFilter extends HttpFilter implements PathExcluder { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like you can also remove PathExcluder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and pull methods out of ServletUtils too! this is fun :-)
dsmiley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought -- perhaps this class should extend Jetty's org.eclipse.jetty.ee10.servlets.IncludeExcludeBasedFilter
On the other hand, maybe there isn't much value in doing so.
| import java.util.regex.Matcher; | ||
| import java.util.regex.Pattern; | ||
|
|
||
| public class PathExclusionFilter extends HttpFilter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should have a bit of documentaton on what it does. Like "if the path matches the configured criteria, we process with the 'default' servlet, that which serves files."
Interesting thought, but looking at that class, I think it's too much of a "Swiss army knife", and employing it will likely add complexity and add extra logic to be executed on each request. |
I think this is because tests don't use static resources. We'll hit this eventually. JettySolrRunner's best/worst feature/failing is that it doesn't load a full web application. Which avoids classpath scanning making it much faster, but also makes it unrealistic. |
https://issues.apache.org/jira/browse/SOLR-18041