What’s the benefit? So you can avoid having a simple core properties file? I’d rather see more value than that prompt exposing something like this to the user. It’s a can of warms that I personally have not seen a lot of value in yet.
Whether we mark it experimental or not, this adds a burden, and I’m still wondering if the gains are worth it. - Mark On Jan 15, 2014, at 12:04 PM, Alan Woodward <a...@flax.co.uk> wrote: > This is true. But if we slap big "warning: experimental" messages all over > it, then users can't complain too much about backwards-compat breaks. My > intention when pulling all this stuff into the CoresLocator interface was to > allow other implementations to be tested out, and other suggestions have > already come up from time to time on the list. It seems a shame to *not* > allow this to be opened up for advanced users. > > Alan Woodward > www.flax.co.uk > > > On 15 Jan 2014, at 16:24, Mark Miller wrote: > >> I think these API’s are pretty new and deep to want to support them for >> users at this point. It constrains refactoring and can complicates things >> down the line, especially with SolrCloud. This same discussion has come up >> in JIRA issues before. At best, I think all the recent refactoring in this >> area needs to bake. >> >> - Mark >> >> On Jan 15, 2014, at 11:01 AM, Alan Woodward <a...@flax.co.uk> wrote: >> >>> I think solr.xml is the correct place for it, and you can then set up >>> substitution variables to allow it to be set by environment variables, etc. >>> But let's discuss on the JIRA ticket. >>> >>> Alan Woodward >>> www.flax.co.uk >>> >>> >>> On 15 Jan 2014, at 15:39, Steven Bower wrote: >>> >>>> I will open up a JIRA... I'm more concerned over the core locator stuff vs >>>> the solr.xml.. Should the specification of the core locator go into the >>>> solr.xml or via some other method? >>>> >>>> steve >>>> >>>> >>>> On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward <a...@flax.co.uk> wrote: >>>> >>>>> 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 >>>>> >>>>> >>> >> >
