Better phrasing actually: Servlets typically generate novel content. On Wed, Oct 23, 2024 at 2:14 PM Gus Heck <gus.h...@gmail.com> wrote:
> It's just decorating an existing resource... adding headers and > filter/replace the content. Servlets typically generate their content. > > On Wed, Oct 23, 2024 at 11:51 AM David Smiley <dsmi...@apache.org> wrote: > >> Why would that be a filter; doesn't a Servlet make sense? >> >> On Wed, Oct 23, 2024 at 11:23 AM Gus Heck <gus.h...@gmail.com> wrote: >> >> > 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) >> > >> > > > -- > 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)
