: > As for component registration precedence, it is the configured Component : > that has precedence. The Component initialization code only adds the : > default Component if that name is not already used. Registering your own : > "spellcheck" Component will use your component. : : Right, but what if someone has a "stats" component now in 1.3 wired into a : custom request handler (but not /select), then upgrades to 1.4 with the new : implicit "stats" built-in - then all of a sudden a request to /select will use : _their_ stats component, not the built in one. Right?
this never really sit well with me before either ... but i couldn't really place why it didn't sit well untill you gave that example. we can't undo the current behavior because it has it's legitimate use cases: i've subclassed QueryComponent to modify it with some custom behavior, and i've registered an instance of MyQueryComponent with the name "query" and now i'm relying on it to get used by default. I think the "solution" to this problem is education and documentation ... people customizing Solr may occasionally have to make some changes when upgrading, it's a fact of life that can't be completely avoided. Consider another equally plausible situation: i have custom response writer in my Solr 1.2 and it uses a request param named "defType" -- which when i upgrade to Solr 1.3 suddenly causes all sorts of things to break, because the param name i picked collides with a new param that all the request handlers i use pay attention to. In the rewuest param collision situation users are *really* screwed, because they have to change the params their clients send ... by comparison, the component name collision situation is trivial to deal with, just search and replace "stats" with "mystats" everywhere in your solrconfig.xml. -Hoss
