Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 87643 invoked from network); 5 Oct 2009 06:27:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Oct 2009 06:27:56 -0000 Received: (qmail 35934 invoked by uid 500); 5 Oct 2009 06:27:55 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 35838 invoked by uid 500); 5 Oct 2009 06:27:54 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 35830 invoked by uid 99); 5 Oct 2009 06:27:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 06:27:54 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [85.25.71.29] (HELO mail.troja.net) (85.25.71.29) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 06:27:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id D324CD36003 for ; Mon, 5 Oct 2009 08:27:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.troja.net Received: from mail.troja.net ([127.0.0.1]) by localhost (megaira.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcZn86xkqaMv for ; Mon, 5 Oct 2009 08:27:21 +0200 (CEST) Received: from VEGA (port-83-236-62-3.dynamic.qsc.de [83.236.62.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTPSA id 64C60D36002 for ; Mon, 5 Oct 2009 08:27:21 +0200 (CEST) From: "Uwe Schindler" To: References: <59b3eb370910021645l154f1ee9p14586927b93fbbef@mail.gmail.com> <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com> <4AC698E4.1050606@gmail.com> <59b3eb370910021918h797027e8qf30761dd22e8f6e5@mail.gmail.com> <4AC7E7D0.8060408@gmail.com> <4AC7FAD5.7030103@gmail.com> <4AC865A3.9060003@gmail.com> <47ACC8E8A54B47DE8750162B0B501CE7@VEGA> <9ac0c6aa0910040253l3d372857v63bc2c44e917c4e5@mail.gmail.com> <20091004223723.GA2973@rectangular.com> Subject: RE: Lucene 2.9 and deprecated IR.open() methods Date: Mon, 5 Oct 2009 08:27:20 +0200 Message-ID: <848CB727CC3949F7AA1D72B0F96F1916@VEGA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpFQ8X4eVNV/rEIS7+5udnqx1MpewAP81dg In-Reply-To: <20091004223723.GA2973@rectangular.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Checked: Checked by ClamAV on apache.org > On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote: > > > 1 Do we prevent config settings from changing after creating an > > IW/IR? > > Any settings conveyed via a settings object ought to be final if you want > pluggable index components. Otherwise, you need some nightmarish > notification > system to propagate settings down into your subcomponents, which may or > may > not be prepared to handle the value modifications. +1, this is an argument in my opinion for final members/settings. By the way, there is a third possibility for passing configuration settings: The idea is to enable passing settings to IR/IW and its flexible indexing components by the same technique like JAXP does it (please don't hit me!): Pass a Properties or Map to the ctor/open. The keys are predefined constants. Maybe our previous idea of an IndexConfiguration class is a subclass of HashMap with all the constants and some easy-to-use setter methods for very often-used settings (like index dir) and some reasonable defaults. This allows us to pass these properties to any flex indexing component without need to modify/extend it to support the additional properties. The flexible indexing component just defines its own property names (e.g. as URNs, URLs, using its class name as prefix,...). Property names are always String, values any type (therefore Map). With Java 5, integer props and so on are no "bad syntax" problem because of autoboxing (no need to pass new Integer() or Integer.valueOf()). Another good thing is, that implementors of e.g. XML config files like in Solr, can simple pass all elements in config to this map. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org