On Wed, Nov 17, 2021 at 11:05 PM Jason Gerlowski <[email protected]> wrote:
> > 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"! > I think we should make it first class. It's more readable > > > 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. > Actually , we can make @EndPoint support v1 as well. But should we > > 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. > The difference is that in the as eof a <requestHandler> the "name" attribute is the path. In case of @EndPoint, the path is hardcoded in the class itself Hence , we probably should introduce a new tag to differentiate > > 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] > > -- ----------------------------------------------------- Noble Paul
