Return-Path: 
 <dev-return-130190-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-dev-archive@www.apache.org
Delivered-To: apmail-lucene-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 67328F553
	for <apmail-lucene-dev-archive@www.apache.org>;
 Tue,  2 Apr 2013 14:49:18 +0000 (UTC)
Received: (qmail 30612 invoked by uid 500); 2 Apr 2013 14:49:16 -0000
Delivered-To: apmail-lucene-dev-archive@lucene.apache.org
Received: (qmail 30524 invoked by uid 500); 2 Apr 2013 14:49:16 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:dev@lucene.apache.org>
List-Id: <dev.lucene.apache.org>
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 30512 invoked by uid 99); 2 Apr 2013 14:49:16 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Apr 2013 14:49:16 +0000
Date: Tue, 2 Apr 2013 14:49:16 +0000 (UTC)
From: "Erick Erickson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12640177.1364854717033.92054.1364914156204@arcas>
In-Reply-To: <JIRA.12640177.1364854717033@arcas>
References: <JIRA.12640177.1364854717033@arcas>
Subject: [jira] [Commented] (SOLR-4662) Finalize what we're going to do with
 solr.xml, auto-discovery, config sets.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619872#comment-13619872 ] 

Erick Erickson commented on SOLR-4662:
--------------------------------------

Hmmmm. Point taken about not exposing a pluggable version yet, now that you mention it that seems premature. Hardening all that before exposing something we then have to support makes sense. We can still program to the interface I mentioned as much as possible to make that easier in future but no big deal either way.

<1> is done.
<2> OK, what does that look like? Is this just a simple transformation like
<solr>
  <solrConfigFactory name="solrConfigFactory" clase="SolrConfigFactory">
    <str name="persistent">${solr.xml.persist:false}</str>
    <str name="adminPath">/admin/cores</str>
    <str name="defaultCoreName">collection1</str>
    <str name="host">127.0.0.1</str>
    <str name="hostPort">${hostPort:8983}</str>
    <str name="hostContext">${hostContext:solr}</str>
    <str name="shareSchema">${shareSchema:false}</str>
  
    <shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
      <int name="socketTimeout">${socketTimeout:120000}</int>
      <int name="connTimeout">${connTimeout:15000}</int>
    </shardHandlerFactory>
  
 
    <str name="zkClientTimeout">${solr.zkclienttimeout:30000}</str>
    <str name="numShards">${numShards:3}</str>
    <str name="distribUpdateConnTimeout">${distribUpdateConnTimeout:15000}</str>
    <str name="distribUpdateSoTimeout">${distribUpdateSoTimeout:120000}</str>
  </solrConfigFactory>
  
</solr>

This form doesn't allow cores to be here at all. Is there any necessity to have a factory here or are you thinking these should just be child nodes of <solr>? Would shardHandlerFactory be inside or outside the new factory? As you can tell, how all this fits together is something of a mystery to me. But having a solrConfigFactory node as the immediate child of <solr> and encompassing all the rest would allow easy detection of old -vs- new style XML. Adding a version attribute to the <solr> tag seems possible too, but I don't really like that, I think there's less user-level maintenance if we use solrConfigFactory, implementing up different handlers for different versions if/when we change again, which should be very rare.

<3> On that note, it's not clear to me we need solr.xml at all in "true cloud mode". In the absence of solr.xml but presence of zkHost, just get everything from ZK. Look, you know how ZK-ignorant I am, be gentle <G>. The rest of the time, anything you could possibly want from solr.xml that wasn't present, ask ZK for it and use defaults if neither source had it. By "not present", that means neither in the solr.xml file nor as a sysprop. Along the way removing DEF_SOLR_XML from ConfigSolrXml would be a Good Thing maybe.
                
> Finalize what we're going to do with solr.xml, auto-discovery, config sets.
> ---------------------------------------------------------------------------
>
>                 Key: SOLR-4662
>                 URL: https://issues.apache.org/jira/browse/SOLR-4662
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 4.3, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Blocker
>
> Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org