Fetcher ignores -noParsing command line option

• Key: NUTCH-413
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Jonathan Amir
• Component/s: fetcher
• Affects Version/s: 0.8.1
• Fix Version/s: 1.0.0

Description

I believe that the patch applied in NUTCH-337 broke the fetcher. Now the fetcher ignores the -noParsing command-line option - the parsing occurs anyway.
To the best of my understanding of nutch, I managed to trace the problem as follows in the code:

In fetcher class, in line 473, -noParsing is evaluted properly and placed into a Configuration created by NutchConfiguartion.create(). So far so good.

In the same file, in line 280, the decision whether to parse or not depends on local field "parsing". During execution, this fields value is true, instead of false. This field is set to true by method "configure", in line 357. The problem is that method "configure" accepts a JobConf as a parameter, but the actual JobConf object that is passed to it is not the one used previously in line 473.
The one that is actually passed to configure is a different object. I think it is created in line 422, but I am not sure about it.

Comments

Are you sure about this? Running the fetcher (latest trunk) with -noParsing option does not create any parse segments, while running fetcher without it does create them. I even put fetcher.parse property in nutch-site.xml(assuming that nutch-site overrides command line options), still it works as expected.

[Jonathan Amir]

I didn't check out the trunk, I checked out the 0.8.1 tag, because I wanted stability. If it is fixed in the trunk, then I guess you can close this issue.
By the way, I wouldn't assume that nutch-site overrides command line options - if it does, then it is wrong. It should be the other way around - command line options should override nutch-site.

[Doğacan Güney]

About command-line options: that is not what I meant(I am not a native speaker). I meant that I also set fetcher.parse to true in nutch-site too to see if there is a bug in that code.

[Andrzej Bialecki]

This is indeed already fixed in trunk.