nutch插件机制

Plugin插件机制为Nutch提供了很强大的扩展性，曾经看到一篇文章《不选择使用Lucene的6大原因》，其中就提到lucene的API不够开放。Lucene的OO设计的非常糟，尽管有包package和类class，但是Lucene的设计基本上没有设计模式的身影。这是不是c或者c++程序员写java程序的通病？Lucene中没有使用接口Interface，等等。在Lucene的2.0版本中就解决了这些问题，同时在Nutch的Plug实现中，完全没有这种问题，正是因为使用了Interface，Nutch的Plugin插件机制才如此的灵活，Nutch的Plugin完全基于Eclipse 2.x中的插件机制。如果你非常了解Eclipse 2.x的插件机制，完全可以跳过Nutch插件机制这一段。

Nutch插件机制
　　Nutch提供插件机制，使得开发人员可以根据自己的需要给Nutch开发适合自己需求的Plugin，完成自己想要的操作。Nutch中所有的分析，索引和查询工作都是通过Nutch的Plugin来实现的。
　　Nutch把自己可以提供的Plugin接口，用一个xml文档来描述。Nutch把这些接口信息，放在Nutch的plugins\nutch-extensionpoints下，Nutch同样认为plugins\nutch-extensionpoints是一个Nutch的Plugin。在plugins\nutch-extensionpoints下的plugin.xml有下面的描述：this file hosts all extension points nutch core code offers. Please not that plugins can define extension points as well to be extendable. 这样所有的Nutch插件都必须是实现自这些extension-points.接口的类。把操作封装成接口，Core Code流程中调用接口方法，标准的Template Pattern。

Nutch是如何加载并调用这些接口的呢？
　　Nutch的PluginRepository是整个插件的加载过程。在installExtensionPoints和installExtensions方法中实现了对整个插件的加载。首先加载插件，然后加载插件的ExtensionPoint。Nutch记录了所有的ExtensionPoint，在每个ExtensionPoint中记录了扩展自这个ExtensionPoints的Extension。通过这种关系就可以通过一个ExtensionPoint(Nutch提供的扩展接口)，得到所有实现了这个接口的类(Extension)。
　　Nutch在自己的某个处理流程中通过Config，得到配置中配置加载的这个流程中需要的Extention。例如AnalyzerFactory的Extension加载过程：
extensionPoint=PluginRepository.get(conf).getExtensionPoint(NutchAnalyzer.X_POINT_ID)
这样所有实现了NutchAnalyzer这个接口的类(Exctesion)将被取得。然后根据需要调用这些接口。在插件的plugin.xml信息中，有一个parameter节点，存储的名值，是描述这个接口的配置信息。共Nutch查找并确定，是否使用这个接口。
　　IndexFilter 中使用Filter的过程。就是一个典型的Nutch使用插件IndexFilter，对Document进行Index的过程。

分词过程
　　Nutch根据不同的语言使用不同的分词器来分词。Nutch如何判定现在分析的网页是那个语言的网页？Nutch使用一个外部Plugin：language-identifier来确定当前分析的网页是那种语言的网页。然后在当前的Document中放入一个名为lang的Field。在进行索引创建和搜索的时候，都会根据lang选择对应语言的Analyzer，如果没有lang的信息，那么Nutch会使用默认的Analyzer对Document建立索引。通过这样的过程就实现了Nutch使用不同的分词器分析不同的网页。
　　如果使用分词，可以直接修改Nutch的Default分词器。根据我个人的测试，language-identifier对中文的网页进行语言定位的使用，有时候很是不准确的。