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)

Reply via email to