+1 to us making the package management adhere to immutable deployments. I'll start work on that soon.
On Wed, 17 Nov, 2021, 3:56 am 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 >>>> >>>
