lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Lucene 2.9 and deprecated IR.open() methods
Date Mon, 05 Oct 2009 08:38:08 GMT
> > See my second mail. The recently introduced Attributes and
> AttributeSource
> > would solve this. Each component just defines its attribute interface
> and
> > impl class and you pass in an AttributeSource as configuration. Then you
> can
> > do:
> >
> > AttributeSource cfg = new AttributeSource();
> >
> > ComponentAttribute compCfg = cfg.addAttribute(ComponentAttribute.class);
> > compCfg.setMergeScheduler(FooScheduler.class);
> >
> > MergeBarAttribute mergeCfg = cfg.addAttribute(MergeBarAttribute.class);
> > mergeCfg.setWhateverProp(1234);
> > ...
> > IndexWriter iw = new IndexWriter(dir, cfg);
> >
> > (this is just brainstorming not yet thoroughly thought about).
> 
> This approach suggests IW creates its components, and while doing so
> provides them your AS instance.
> I personally prefer creating all these components myself, configuring
> them (at the moment of creation) and passing them to IW in one way or
> another.
> This requires way less code, you don't have to invent elaborate
> schemes of passing through your custom per-component settings and
> selecting which exact component types IW should use, you don't risk
> construct/postConstruct/postpostConstruct-style things.


Not really. That was just brainstorming. But you can pass also instances
instead of class names through attributesource. AttributeSurce only provides
type safety for the various configuration settings (which are interfaces).
But you could also create an attribute that gets the pointer to the
component. So "compCfg.setMergeScheduler(FooScheduler.class);" could also be
compConfig.addComponent(new FooScheduler(...));

The AttributeSource approach has one other good thing:
If you want to use the default settings for one attribute, you do not have
to add it to the AS (or you can forget it). With the properties approach,
you have to hardcode the parameter defaults and validation everywhere. As
the consumer of an AttributeSource gets the attribute also by an
addAttribute-call (see current indexing code consuming TokenStreams), this
call would add the missing attribute with its default settings defined by
the implementation class. So in the above example, if you do not want to
provide the "whateverProp", leave the whole MergeBarAttribute out. The
consumer (IW) would just call addAttribute(MergeBarAttribute.class), because
it needs the attribute to configure itself. AS would add this attribute with
default settings.

Uwe


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


Mime
View raw message