Tom, I did make an effort to "sort out" both the old and newer solr.xml
features in my Solr 4.x Deep Dive e-book.
-- Jack Krupansky
-----Original Message-----
From: Tom Burton-West
Sent: Wednesday, February 5, 2014 5:56 PM
To: solr-user@lucene.apache.org
Subject: Re: Default core for updates in multicore setup
Thanks Hoss,
hardcoded default of "collection1" is still used for
backcompat when there is no "defaultCoreName" configured by the user.
Aha, it's hardcoded if there is nothing set in a config. No wonder I
couldn't find it by grepping around the config files.
I'm still trying to sort out the old and new style solr.xml/core
configuration stuff. Thanks for your help.
Tom
On Wed, Feb 5, 2014 at 4:31 PM, Chris Hostetter
<hossman_luc...@fucit.org>wrote:
: I then tried to locate some config somewhere that would specify that the
: default core would be collection1, but could not find it.
in the older style solr.xml, you can specify a "defaultCoreName". Moving
forward, relying on the default core name is discouraged (and will
hopefully be removed before 5.0) so it's not possible to configure it in
the new core discovry style of solr.xml...
https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
For now owever, the hardcoded default of "collection1" is still used for
backcompat when there is no "defaultCoreName" configured by the user.
and things like post.sh, post.jar, and the tutorial have not really been
updated yet to reflect that the use of the default core name is
deprecated.
: 2) I ran across SOLR-545 which seems to imply that the current behavior
: (dispatching the update requests to the core named collection1) is a bug
Yeah, A lot of things have changed since 1.3 ... not sure when exactly the
configurable defaultCoreName was added, but it was sometime after that
issue i believe.
-Hoss
http://www.lucidworks.com/
