Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@locus.apache.org Received: (qmail 93590 invoked from network); 5 Feb 2007 06:01:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Feb 2007 06:01:45 -0000 Received: (qmail 49769 invoked by uid 500); 5 Feb 2007 06:01:51 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 49738 invoked by uid 500); 5 Feb 2007 06:01:51 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 49729 invoked by uid 99); 5 Feb 2007 06:01:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Feb 2007 22:01:51 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [169.229.70.167] (HELO rescomp.berkeley.edu) (169.229.70.167) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Feb 2007 22:01:42 -0800 Received: by rescomp.berkeley.edu (Postfix, from userid 1007) id 3BAF65B771; Sun, 4 Feb 2007 22:01:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rescomp.berkeley.edu (Postfix) with ESMTP id 2FC357F403 for ; Sun, 4 Feb 2007 22:01:22 -0800 (PST) Date: Sun, 4 Feb 2007 22:01:22 -0800 (PST) From: Chris Hostetter To: solr-dev@lucene.apache.org Subject: Re: finer granularity of configuration In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org : Here's an off-the-cuff idea... what if we hook Config.get() to look : for system properties that would override configuration values. : SolrCore does this: the number of different system properties could get very messy ... i'd much rather see a good patch for SOLR-79 (one thought i had rereading the issue is that the property replacement could happen when the config was parsed into the DOM tree at stratup -- then all of the various methods used to get config values wouldn't need to be changed -- jus hte parsing). another way to make this more customizable, would be to make sure we support Xinclude when parsing xml config files... http://www.w3.org/TR/2004/PR-xinclude-20040930/ -Hoss