Okay, if anyone wants to look at https://github.com/apache/solr/pull/1810, I think we’re ready for review. I ran the BATS tests locally and they passed, barring `test_placement_plugin.bats` which has often failed for me.
We can keep this change on main, though there is a LOT of change, so it make make back porting progressively harder? What was driving this for me was the CLI changes, which also look to stay on main for now anyway. > On Jul 28, 2023, at 3:22 PM, Gus Heck <gus.h...@gmail.com> wrote:` > > That's precisely how we currently pretend /api isn't part of /solr right > now (it's actually /solr/____v2) > > https://github.com/apache/solr/blob/main/solr/server/etc/jetty.xml#L149 > > On Fri, Jul 28, 2023 at 1:38 PM Mark Miller <markrmil...@gmail.com> wrote: > >> If you are just looking for a “path”, you could add a rewrite rule to >> jetty.xml as an equivalent I believe. >> >> On Fri, Jul 28, 2023 at 11:13 AM Jason Gerlowski <gerlowsk...@gmail.com> >> wrote: >> >>>> I discovered that the “hostContext”, i.e the “/solr” bit of the URL can >>> actually be changed! >>> >>> 1. I wonder if/how this works outside of tests. Looking at jetty.xml, >>> there's plenty of hardcoding of "/solr" in rewrite rules, etc. >>> >>> 2. I like the idea of having a configurable context-root in theory. >>> I've found it useful in the past e.g. when proxying traffic to Solr >>> through NGINX etc. But the way Solr works now, "/solr" isn't really a >>> context-root - it's only present in our v1 APIs. (IMO that's the real >>> problem that SOLR-16800 runs into - it wants to nudge users into >>> providing api-agnostic base URLs, but "/solr" is v1 specific) So at >>> least in its current form it's hard to defend keeping around. If we >>> do go ahead with removing it now, maybe it'd be worth re-adding >>> support later, where the default context-root would be "/" and serve >>> as a prefix for both v1 and v2 APIs. >>> >>>> Would this be something that *could* be back ported to branch_9x? >>> >>> Would there be any sort of an upgrade path for a 9.3 user to upgrade >>> to (say) 9.5? If not, then it seems like the sort of breaking change >>> that we can't really backport (beyond maybe a log message that warns >>> 9.x deploys configured with non-default context roots, etc.) >>> >>> Best, >>> >>> Jason >>> >>> On Fri, Jul 28, 2023 at 11:39 AM Eric Pugh >>> <ep...@opensourceconnections.com> wrote: >>>> >>>> I opened https://github.com/apache/solr/pull/1810 >>>> >>>> Would this be something that *could* be back ported to branch_9x? I >>> added a test that if you have a hostContext defined in your solr.xml, it >> is >>> ignored in favour of /solr. I don’t have any special logging around it >>> however. >>>> >>>> Eric >>>> >>>> >>>>> On Jul 27, 2023, at 10:48 PM, Gus Heck <gus.h...@gmail.com> wrote: >>>>> >>>>> TLDR; I support removing configurability, but not the long term >>>>> immutability of /api's current location. >>>>> >>>>> Cleaning up weirdness and inconsistency seems good, but I don't >> really >>> like >>>>> the fact that we occupy root context, and I was with you until you >>>>> advocated setting /api in stone. >>>>> >>>>> I find it entirely regrettable that we moved API to /api rather than >>>>> /solr/api >>>>> >>>>> @David We are STILL a webapp in a servlet container. Until we ditch >>> Jetty >>>>> that will always be true. I don't think we should ignore servlet >>> container >>>>> best practices just because we only support one servlet container. We >>>>> should be developing toward >>>>> >>>>> - Breaking our bloated swiss army knife filter into a series of >>>>> composable filters >>>>> - Converting major functional areas currently baked into the filter >>> into >>>>> independent servlets that each re-use said filters (query, update, >>> admin >>>>> seem natural candidates to each be a separate servlet. >>>>> - Ensuring that our functional core code is not handling dispatch >> and >>>>> passthrough logic by ensuring that the UI is it's own app (and it >> can >>>>> re-use some filters too, like authn/authz oriented which should be >>> separate >>>>> filters) >>>>> - leaving ourselves latitude to think of creative new ways of >>> leveraging >>>>> our container (or not) by not squatting on the root context. >>>>> - Leaving the option that creative folks can create companion apps >>> other >>>>> than the UI... maybe doing things like tracking docs added, >>> listening for >>>>> commit events and notifying an indexer that a document is now >>>>> searchable... It certainly would be better if that sort of thing >>> was in a >>>>> user supplied war deployed into our jetty than if they have to >>> customize >>>>> our code directly... (publishing events somewhere they can get hold >>> of it >>>>> within Jetty would have to be added, but that's generic and >>> re-usable). >>>>> >>>>> Note that all of this remains true no matter how we start jetty... >>> Jetty is >>>>> still there, and still calculating dispatch to our servlet context, >> no >>>>> matter what we do. If we want to ditch Jetty entirely, then that's an >>>>> entirely different matter. In that case, we certainly can specify any >>> URL >>>>> patterns we like because THEN we ARE writing the server. Since day >> one >>>>> however we've always been writing an application, albeit an oddly >>> shaped >>>>> one.There's no technical benefit to eliminating /solr or anything >> like >>> that >>>>> (if you really care about length I'm happy to meet you 3/4 of the way >>> at /s >>>>> instead of /solr). It's an aesthetic for a bike shed that is built >>> right >>>>> where we might someday want a barn or a garage, etc. (and yes to the >>> irony >>>>> of me writing a long email about it! :) ). >>>>> >>>>> So yes to making /solr not user configurable, No to the idea that >> /api >>> can >>>>> never move. Both those locations usage in the tests should maybe be >>> based >>>>> on a simple hard coded constant or something simple like that (in >> case >>>>> someone does want /s in the future ;) ), but there certainly >> shouldn't >>> be >>>>> complex logic trying to divine the name of our context or anything >> like >>>>> that. >>>>> >>>>> -Gus >>>>> >>>>> On Thu, Jul 27, 2023 at 9:37 PM Ishan Chattopadhyaya < >>>>> ichattopadhy...@gmail.com> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Fri, 28 Jul, 2023, 1:56 am Eric Pugh, < >>> ep...@opensourceconnections.com> >>>>>> wrote: >>>>>> >>>>>>> Hi all…. In working on SOLR-16800, which let’s us pass in a >>> -solrUrl >>>>>>> that is “http://localhost:8983 <http://localhost:8983/>” instead >> of >>> the >>>>>>> current “http://localhost:8983/solr”. This will set us up in >> the >>>>>>> future when V2 api’s get called, and they are under “ >>>>>>> http://localhost:8983/api” ;-). >>>>>>> >>>>>>> As part of that effort, I discovered that the “hostContext”, i.e >> the >>>>>>> “/solr” bit of the URL can actually be changed! For example, “ >>>>>>> http://localhost:8983/uf” is a valid Solr URL. >>>>>>> >>>>>>> There is a bunch of plumbing around hostContext in our tests, >>> including >>>>>>> some randomization. See initHostContext and >>>>>>> getHostContextSuitableForServletContext in >>> BaseDistributedSearchTestCase >>>>>>> for example. >>>>>>> >>>>>>> However, I am wondering if there is actually a valid use case for >>> this? >>>>>>> Especially since in the future, with our V2 api’s, they won’t be >>> using >>>>>> this >>>>>>> hostContext variability, they will always be under /api path. >>>>>>> >>>>>>> I’d like to rip out the ability to change the hostContext in 10.x >>> (and if >>>>>>> folks are up for it, back port to 9x) and establish that it’s >> always >>>>>> /solr >>>>>>> for existing paths, and /api for the v2 API. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Eric >>>>>>> _______________________ >>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | >>> 434.466.1467 | >>>>>>> http://www.opensourceconnections.com < >>>>>>> http://www.opensourceconnections.com/> | My Free/Busy < >>>>>>> http://tinyurl.com/eric-cal> >>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>>>>>> >>>>>> >>> >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>>>>>> >>>>>>> >>>>>>> This e-mail and all contents, including attachments, is considered >>> to be >>>>>>> Company Confidential unless explicitly stated otherwise, regardless >>> of >>>>>>> whether attachments are marked as such. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> http://www.needhamsoftware.com (work) >>>>> http://www.the111shift.com (play) >>>> >>>> _______________________ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | >>> http://www.opensourceconnections.com < >>> http://www.opensourceconnections.com/> | My Free/Busy < >>> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>> >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>>> >>>> This e-mail and all contents, including attachments, is considered to >> be >>> Company Confidential unless explicitly stated otherwise, regardless of >>> whether attachments are marked as such. >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>> -- >> - MRM >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
