> > I'd prefer it being an explicit fallback or resolution order instead of > hardcoded magick. > I.e. able to configure a configset search path such as ["local", "zk", > "somethingelse"]. This would make resource loader prefer local files even > if they exist in ZK. > > This actually winds up being a convention vs configuration thing I think. Complexity is situational sometimes. Having a fallback convention means that when you are experienced, you can walk into any install and know what's going on, but if you are new, there's a learning curve. On the other hand if we allow resolution order to be configurable, then one never knows what's going on until you've first got an answer to "how's it been configured". This can sometimes be a little simpler for first timers, except that certain configurations might be a bad idea, and then they won't see the rope until they are all tangled up in it. So for a consultant, or new hire with experience the convention path is simpler, because one always looks at specific things in a specific order that is already known. The configuration path is only sometimes simpler for new users.
However, what I'd propose is that we have a precedence order for the "levels" of configuration, and a single "source" for configuration.... if we need to make that source configurable so be it, but all "primary configuration" should come from a single source, for a given cluster. To put it another way I'm not fond of any "fallback" in where config comes from. By "Primary configuration" I mean the solr specific xml/json/whatever ... The "Primary Configuration" could of course point to resources required elsewhere, but those should be things like jar files or SSO systems, whereas the configuration artifacts that are solr specific should come from one source. -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
