Stefan Groschupf wrote:
> My suggestion is that we change NutchConf is following way:
>
> resourceNames.add(resourceNames.size()-1, name); // add second to last
> loadResource(properties, name, false);
This would make property settings in the new resource (name, in the above)
override explicitly set() properties and the final site settings
could be overridden by a lower priority config file.
In TestNDFS, I relied on explicitly set() properties to make the
test *independent* of the conf files (even to the point of overriding
nutch-site.xml).
I recommend filing a bug and I will then submit a patch.
Details:
The problem here is that NutchConf puts all the attribute-value pairs
in a single Properties instance. It should use the existing mechanism
of Properties which can chain together as an implicit linked list of defaults.
In the most straightforward approach, each resource should get an
instance of Properties and a separate, highest priority, Properties
instance should be used to hold explicitly set value.
In Java:
Properties props, deep, deeper, deepest;
props = new Properties(deep = new Properties(deeper = new
Properties(deepest = new Properties())));
and
NutchConf.set(a,v) would simply use props.setProperty(a,v)
loadResource(deep, "nutch-site.xml", false);
loadResource(deeper, name, false);
loadResource(deepest, "nutch-default.xml", false);
The actual implementation would need to deal with a variable number of
Properties, not just 3.
Paul
