Hi,
This is what i did to make NutchConf behave not so static,
without patching any of those 195 places Stefan mentioned.
NutchConf.get() yields the current config.
OpenConf sets a new current config.
finally CloseConf closes this config.
But be warned about issues with the plugin cache menti
Andrzej,
well I'm not ready with digging into the problem but want to ask some
more questions.
BTW I counted 195 places that use NutchConf.get(), so this will be a
bigger patch. :)
As I mentioned I would love to go the inversion of control way, so
not using nutchConf in the constructor but
Hi,
right this is a know problem and discussed several times, we should
start solving this. :-)
I suggest that we make the Plugin Class implementing the Configurable
interface. In case a plugin needs any configuration value it will
request them from the plugin instance.
The next step would b
Jérôme Charron wrote:
Andrzej,
How do you choose the NutchConf to use ?
It is provided as an argument to all constructors.
Here is a short discussion I had with Doug about a kind of dynamic NutchConf
inside the same JVM:
"... By looking at the mailing lists archives it seems that having
Andrzej,
How do you choose the NutchConf to use ?
Here is a short discussion I had with Doug about a kind of dynamic NutchConf
inside the same JVM:
"... By looking at the mailing lists archives it seems that having some
behavior depending on the documents URL is a recurrent problem (for instance
Andrzej Bialecki wrote:
URLFilters:
private URLFilters(NutchConf) {
// initialize plugins based on this instance of NutchConf
}
public static URLFilters get(NutchConf conf) {
URLFilters res = (URLFilters)conf.get("urlfilters.key");
if (res == null) {
res = n
