Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: "Uwe Schindler" <uwe@thetaphi.de>
To: <java-dev@lucene.apache.org>
References: <59b3eb370910021645l154f1ee9p14586927b93fbbef@mail.gmail.com>
 <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com>
 <4AC698E4.1050606@gmail.com>
 <59b3eb370910021918h797027e8qf30761dd22e8f6e5@mail.gmail.com>
 <4AC7E7D0.8060408@gmail.com>
 <c7d45fc70910031826o2822e143i28ad541ab2a31ca5@mail.gmail.com>
 <4AC7FAD5.7030103@gmail.com> <4AC865A3.9060003@gmail.com>
 <47ACC8E8A54B47DE8750162B0B501CE7@VEGA>
 <9ac0c6aa0910040253l3d372857v63bc2c44e917c4e5@mail.gmail.com>
 <20091004223723.GA2973@rectangular.com>
 <848CB727CC3949F7AA1D72B0F96F1916@VEGA>
Subject: RE: Lucene 2.9 and deprecated IR.open() methods
Date: Mon, 5 Oct 2009 09:15:26 +0200
Message-ID: <A6E6AD66AF274062A8A53F2B5AA05223@VEGA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcpFQ8X4eVNV/rEIS7+5udnqx1MpewAP81dgAAH14pA=
In-Reply-To: <848CB727CC3949F7AA1D72B0F96F1916@VEGA>

> > 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<String,?> to the ctor/open. The keys are
> predefined
> constants. Maybe our previous idea of an IndexConfiguration class is a
> subclass of HashMap<String,?> 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<String,?>). 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.

Another option for extensibility with type safety, properties would not
have, would be Attributes. Just pass an AttributeSource as configuration.
And the default index properties are one attribute where custom extensions
can define own ones.

Uwe


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