: I don't mind Solr being a "webapp" in Jetty. I don't recall it
: constraining us or being interfering. Jetty is very customizable so we can
: tweak the Jetty-Solr relationship to our liking. A webapp makes it
: straightforward (no code!) for other users to add a CORS Filter in Solr or
: to a
I don't mind Solr being a "webapp" in Jetty. I don't recall it
constraining us or being interfering. Jetty is very customizable so we can
tweak the Jetty-Solr relationship to our liking. A webapp makes it
straightforward (no code!) for other users to add a CORS Filter in Solr or
to add another w
: 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.
Once upon a time (before solr even supported multi-core) there was a
SolrServlet bound to /select
Better phrasing actually: Servlets typically generate novel content.
On Wed, Oct 23, 2024 at 2:14 PM Gus Heck 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 Dav
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 wrote:
> Why would that be a filter; doesn't a Servlet make sense?
>
> On Wed, Oct 23, 2024 at 11:23 AM Gus Heck w
Why would that be a filter; doesn't a Servlet make sense?
On Wed, Oct 23, 2024 at 11:23 AM Gus Heck 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 str
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 A
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 We
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, Oc
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
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
ServletFilt
11 matches
Mail list logo
