Hmmmm. Does it make sense then to allow this parameter for new-style solr.xml (small code change I think, although I haven't looked) on 4.x _only_ while we make trunk happy?
On Wed, May 8, 2013 at 6:47 PM, Chris Hostetter <[email protected]> wrote: > > https://issues.apache.org/jira/browse/SOLR-4803 > https://issues.apache.org/jira/browse/SOLR-4804 > > > : Date: Wed, 8 May 2013 15:30:50 -0700 (PDT) > : From: Chris Hostetter <[email protected]> > : To: Lucene Dev <[email protected]> > : Subject: Re: [JENKINS] Lucene-Solr-SmokeRelease-4.x - Build # 69 - Failure > : > : > : : OK, let me see if I understand the state here. We're not so suspicious > : : of SOLR-4773 any more, right? We now suspect the default collection > : : issue. > : > : there *was* a problem that looked like SOLR-4773, but there is now > : currently a problem because the example setup doesn't support default > : core name. > : > : things like post.jar, and test_utf8.sh and almost all of the examples on > : the wiki will assume that urls like > : "http://localhost:8983/solr/select?q=foo"; will still work and will access > : the default "collection1". > : > : "ant nightly-smoke" is a way to see all of the basic smoke test that > : happen before we can release that are currently broken because of this -- > : we could change those sanity checks to be explict about using > : "collection1" in the URL -- but in some cases that's going to require > : conceptual changes to things like post.jar to start making the URL (or at > : least the core name) mandatory instead of optional, so it should probably > : thought out more carefully and tracked explicitly in jira. > : > : I started looking into how to re-configuring the example to re-enable > : "collection1" as the default collection name for now so that we could get > : the smoke tester working again on both 4x and trunk, and then iterate on > : updatingthe examples for trunk (since miller implied phasing out default > : core name was only intentional on trunk) but from what i can tell the > : "new" style solr.xml has no way of specifying a default collection name at > : all. it's explicitly only supported uisng hte old style config... > : > : if (cfg instanceof ConfigSolrXmlOld) { //TODO: Remove for 5.0 > : String dcoreName = > cfg.get(ConfigSolr.CfgProp.SOLR_CORES_DEFAULT_CORE_NAME, null); > : > : ... i think perhaps even if the new style syntax has no way for hte user > : to explicitly specify a default core name, we should at least continue to > : assume the hardcoded DEFAULT_DEFAULT_CORE_NAME for the "new style" config > : to keep the examples working, and to keep simple urls for people who start > : with "collection1" and never add any other collections. > : > : i'll experiment with that and see how far i get... > : > : > : > : -Hoss > : > > -Hoss > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
