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)
