SOLR-13553 was reverted; SOLR-14404 is what replaced it; shipped in 8.6. The issue I refer to above SOLR-15782 links to the latter as a new way to register these plugins in solr.xml instead of having to do so at-runtime. Plugging in at runtime is neat but let's not discount the value / benefits of configuration that can be tested/deployed immutably / statically -- immutable infrastructure ( https://www.bmc.com/blogs/immutable-infrastructure/ ). I think that we'd be further along in adoption of the plugin system if it had 1st class support for this -- static first, runtime later. I raised a thread earlier about this notion relating to some other configuration we have -- https://lists.apache.org/thread/3vvld3xnndtthtl7sfgdbsgkbtpm55b0
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Nov 16, 2021 at 12:10 PM Ishan Chattopadhyaya < [email protected]> wrote: > I was referring to https://issues.apache.org/jira/browse/SOLR-13553. > > On Tue, 16 Nov, 2021, 10:38 pm Ishan Chattopadhyaya, < > [email protected]> wrote: > >> Those new @endpoint ones are the ones that are loadable via packages >> (node/cluster level plugins), right? IIRC, there's a Zookeeper handler that >> Noble introduced that way. I feel we should put our weight behind it so >> that we can (at some point in time) decouple such handlers from solr-core >> module and plugin at runtime. >> >> On Tue, 16 Nov, 2021, 8:34 pm David Smiley, <[email protected]> wrote: >> >>> I'm looking in CoreContainer and it appears we have two fundamentally >>> different ways of implementing node level handlers/endpoints/APIs (whatever >>> you might want to call them) to respond to requests. There is the original >>> SolrRequestHandler interface, which certainly isn't going away, at least >>> for use in a core. It has decent javadocs and it refers to the SolrCore a >>> lot strongly suggesting they are only associated at a core level (which I >>> know not to be true; it's used for many CoreContainer APIs). And it >>> appears there are now @EndPoint annotated methods on classes that needn't >>> implement anything. It has no javadocs :disappointed: although admittedly >>> it's fairly intuitive. I suppose new functionality at the CoreContainer >>> level should never be the old SolrRequestHandler way? If true; it would be >>> good to deprecate it w/ comments. >>> >>> Some context: I'm working with Nazerke to make it so that you can >>> register these in solr.xml SOLR-15782 and it's not evident if we should use >>> <requestHandler .../> terminology to mimic that in solrconfig.xml >>> (familiarity with developers) or to use something else. Maybe we could >>> detect at runtime if the class is a SolrRequestHandler vs something >>> annotated with @EndPoint? I don't know. Perhaps >>> SolrRequestHandler.handleRequest should itself be labelled with @EndPoint. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>
