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
