nutch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Groschupf>
Subject Re: no static NutchConf
Date Sun, 08 Jan 2006 15:08:04 GMT
as mentioned...
All these classes will implement the NutchConfigurable interface. The  
plugin system will instantiate these objects and inject the nutch  
configuration object *BEFORE* it will return the object instance to  
the caller object.
So we can be sure that setConf is called before any e.g. parse method  
is called.
So the answer is the fields will be setted / intialized in the  
setConf method that need to be implemented by each extension class  
and we have the agreement that this method is called directly after  
the constructor but before any other call.
Does that clarify my suggestion?


Am 08.01.2006 um 15:49 schrieb Marko Bauhardt:

>> + Getting a Extension, require also a NutchConf that is injected  
>> in case the Extension Object (e.g. a Parser) implements a  
>> Configurable interface.
> I think this is a good idea. But many plugins like  
> BasicIndexingFilter or ExtParse require some fileds in the "parse"  
> or "filter" method. These fields are  load over the static way  
> (over static NutchConf or static blocks). And this is ok, because  
> the fields are load only one time. If we load the fields in the  
> "parse" or "filter" methods, the fields would be load many times.  
> And this is a performance problem.
> The initialization of the fields over the constructor does not  
> work, because setConf() is calling after the constructor.
> Should we add a method like "loadNutchConfiguration()" to the  
> NutchConfigurable interface, to load the NutchConfiguration  
> Parameter? Hm, i don't know.
> Should the fields are loading in the setConf() method? Hm, the name  
> of the method says: set the NutchConf and not load the required  
> NutchConfiguration-Parameter.
> Has anyone an other elegant solution?
> Marko


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message