I was referring to https://issues.apache.org/jira/browse/SOLR-13553.
On Tue, 16 Nov, 2021, 10:38 pm Ishan Chattopadhyaya, < ichattopadhy...@gmail.com> 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, <dsmi...@apache.org> 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 >> >
