> I'm working with Nazerke to make it so that you can register these in > solr.xml SOLR-15782
Awesome, glad to hear you guys are looking at this and making @Endpoint APIs a little more "first class"! > it's not evident if we should use <requestHandler .../> terminology to mimic > that in solrconfig.xml (familiarity with developers) or to use something else >From what I've seen anecdotally and Ishan's said here, it sounds like the requestHandler/Endpoint distinction breaks down along v1/v2 API lines. i.e. there are no v1 Endpoints, just v1 requestHandlers. To me that suggests you'd be justified in introducing a new terminology here if you want to and it makes sense. I guess the question I'd have is how similar your solrconfig.xml support will be to the current requestHandler terminology. If you end up implementing registration in a way that gives Endpoints some sort of single "init" method to invoke upon registration - well that's pretty much the same interface as SolrRequestHandler, so maybe sticking with 'requestHandler' terminology makes sense. OTOH if the registration process looks "different enough", then it probably deserves its own terminology. Just my two cents. Best, Jason On Tue, Nov 16, 2021 at 5:26 PM David Smiley <[email protected]> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
