Hi Steve, I think this is a great idea. Currently the implementation of CoresLocator is picked depending on the type of solr.xml you have (new- vs old-style), but it should be easy enough to extend the new-style logic to optionally look up and instantiate a plugin implementation.
Core loading and new core creation is all done through the CL now, so as long as the plugin implemented all methods, it shouldn't break the Collections API either. Do you want to open a JIRA? Alan Woodward www.flax.co.uk On 14 Jan 2014, at 19:20, Erick Erickson wrote: > The work done as part of "new style" solr.xml, particularly by > romsegeek should make this a lot easier. But no, there's no formal > support for such a thing. > > There's also a desire to make ZK "the one source of truth" in Solr 5, > although that effort is in early stages. > > Which is a long way of saying that I think this would be a good thing > to add. Currently there's no formal way to specify one though. We'd > have to give some thought as to what abstract methods are required. > The current "old style" and "new style" classes . There's also the > chicken-and-egg question; how does one specify the new class? This > seems like something that would be in a (very small) solr.xml or > specified as a sysprop. And knowing where to load the class from could > be "interesting". > > A pluggable SolrConfig I think is a stickier wicket, it hasn't been > broken out into nice interfaces like coreslocator has been. And it's > used all over the place, passed in and recorded in constructors etc, > as well as being possibly unique for each core. There's been some talk > of sharing a single config object, and there's also talk about using > "config sets" that might address some of those concerns, but neither > one has gotten very far in 4x land. > > FWIW, > Erick > > On Tue, Jan 14, 2014 at 1:41 PM, Steven Bower <smb-apa...@alcyon.net> wrote: >> Are there any plans/tickets to allow for pluggable SolrConf and >> CoreLocator? In my use case my solr.xml is totally static, i have a >> separate dataDir and my core.properties are derived from a separate >> configuration (living in ZK) but totally outside of the SolrCloud.. >> >> I'd like to be able to not have any instance directories and/or no solr.xml >> or core.properties files laying around as right now I just regenerate them >> on startup each time in my start scripts.. >> >> Obviously I can just hack my stuff in and clearly this could break the >> write side of the collections API (which i don't care about for my case)... >> but having a way to plug these would be nice.. >> >> steve
