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
