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)
