> 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
