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.
