Found the PR, approved, Side note: It looks like AdminUIServlet is another candidate for a filter since it's manually loading a static html file and then feeding it to the out stream ( I think HttpServletResponseWrapper can be used to do the version substitution)...
On Wed, Oct 23, 2024 at 9:30 AM Gus Heck <gus.h...@gmail.com> wrote: > As for next steps, I was planning on heading for creation of filters next, > so that when a servlet is create it can just be configured with all the > same filters. That way the old dispatch filter can continue to do it's > thing without requiring all 3 aspects to be migrated to a servlet at once. > > On Wed, Oct 23, 2024 at 9:27 AM Gus Heck <gus.h...@gmail.com> wrote: > >> Absolutely one step at a time. We've seen in the past how an enormous >> change is just too hard to work back into the mainline, and I'd hate to put >> in the effort only to suffer that fate. Review is always welcome of course! >> I'll check for that review you requested. I might have missed it. >> >> On Tue, Oct 22, 2024 at 11:06 PM David Smiley <dsmi...@apache.org> wrote: >> >>> Hmm, quite some ideas there :-) >>> >>> One step at a time, though I'm not sure I agree with the destination you >>> fantasized about. Would the next step "just" be a matter of splitting >>> out >>> the parts of SolrDispatchFilter that are not very filter-y and creating a >>> SolrServlet from that? Don't need to retain any dubious things >>> like excludePatterns or "passthrough". Thinking of Solr 10 here; more >>> freedom to do something different that works but might break <1% of users >>> for some obscure thing. FWIW I'd be happy to be a code reviewer. I >>> tagged >>> you for a review on something nearby the other day. >>> >>> On Tue, Oct 22, 2024 at 5:35 PM Gus Heck <gus.h...@gmail.com> wrote: >>> >>> > Converting Solr to a servlet, or even a query servlet, an update >>> servlet >>> > and an admin servlet because those are really very separate operations >>> has >>> > been on my mind for a long time. The overlap among those operations is >>> all >>> > in things like authentication or tracing that should be reusable >>> > ServletFilters, is one of those things I have long thought about, and >>> these >>> > thoughts are part of why I moved CoreContainer Initialization out of >>> the >>> > very bloated SolrDispatchFilter. Having CoreContainer exist before any >>> > processing code is initialized or invoked was a critical first step to >>> any >>> > disassembly into a series of reusable filters and/or separation of >>> > concerns. There's an even more radical possibility of making >>> CoreContainer >>> > a container (jetty) level resource, and separating the >>> update/admin/query >>> > bits into entirely distinct web applications... any of which might not >>> be >>> > installed in a particular running jetty. (assuming use sort of >>> replication >>> > to transfer indexes to installations hosting the query app... ) That's >>> > pretty radical though, and servletization (TM) and separation of >>> concerns >>> > come first anyway. >>> > >>> > My recent web-socket stuff is also a sideways exploration of ways to >>> get a >>> > separate thing running inside our code base. Originally, I'd hoped to >>> make >>> > it a separate servlet, but we don't have any notion in our code base >>> of how >>> > to twiddle/tweak/adjust what's deployed via web.xml. I spent some time >>> > thinking about the possibility of web-fragment.xml usage, but there's >>> an >>> > important tension there with startup time and classpath scanning. Our >>> > classpath is gigantic so I'm loath to unset the metadata-complete=true >>> > < >>> > >>> https://github.com/apache/solr/blob/main/solr/webapp/web/WEB-INF/web.xml#L22 >>> > > >>> > and so it wound up in the module world instead... >>> > >>> > I hack on things related to this occasionally, but it's a big project >>> that >>> > likely will take me a very long time to work through on my own unless >>> I get >>> > lucky and find a sponsor that allows me to work on it full time... >>> > >>> > -Gus >>> > >>> > On Tue, Oct 22, 2024 at 4:51 PM David Smiley <dsmi...@apache.org> >>> wrote: >>> > >>> > > 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. >>> > > >>> > > Why I'm bringing this up: >>> > > I heard of HTTP 404 responses coming from a Solr server I run, but >>> didn't >>> > > see the request in our Solr logs. It turns out that requests into >>> Solr >>> > to >>> > > a non-existent core are not logged by Solr. A 404 made sense of >>> course, >>> > > and that's what happened, so there's no bug but the logging >>> situation is >>> > > disappointing. By code inspection, I see that SolrDispatchFilter >>> will do >>> > > the PASSTHROUGH case if it can't find the core. Jetty ultimately >>> gets it >>> > > (default servlet?) and returns the 404 and HTML in our >>> "error404.html". >>> > > Furthermore, I have also recently seen error scenarios where Solr >>> does >>> > > handle the request but doesn't log it *unless* it's a 500 (see >>> > > ResponseUtils). Shouldn't we want at least one *Solr* log message >>> for >>> > > every request to Solr and no matter the HTTP status? I'm aware >>> Jetty has >>> > > logs but it's a patchwork between looking at both. >>> > > >>> > > ~ David Smiley >>> > > Apache Lucene/Solr Search Developer >>> > > http://www.linkedin.com/in/davidwsmiley >>> > > >>> > >>> > >>> > -- >>> > http://www.needhamsoftware.com (work) >>> > https://a.co/d/b2sZLD9 (my fantasy fiction book) >>> > >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> https://a.co/d/b2sZLD9 (my fantasy fiction book) >> > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
