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 >
