采用Ant进行诊断测试

核心提示： 用户可能碰到什么样的问题呢？首先，假如用户没有完全按照正确的安装步骤，采用Ant进行诊断测试，在安装过程中就可能会出现问题了，即使安装成功了，然后你就可以使用已知的正确版本来替换被改变的类文件了，另一方面，之后问题仍然可能出现，配置（像java_HOME环境变量）的改变或者目录结构的

　　用户可能碰到什么样的问题呢？首先，假如用户没有完全按照正确的安装步骤，在安装过程中就可能会出现问题了。即使安装成功了，之后问题仍然可能出现。配置（像java_HOME环境变量）的改变或者目录结构的改变无疑会导致问题。在本文中，我们将要开发一个Ant脚本来为一个Java程序运行诊断测试。我们将着眼于建立一个可能出现的问题的列表以及如何来解决这些问题。Ant需要提前被安装在用户的机器上，这意味着你的安装程序可能需要提供Ant。

　　系统配置

　　在除错时你需要知道的第一件事就是系统配置——操作系统，Java版本，类路径等等。由于Ant提供了对所有Java系统属性的访问，实现这一功能是很轻易的。下面是一个示例：

　　　　　　basedir=".">

　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　

　

　　示例将有如下输出：

$ ant -f diagnostic.xml
Buildfile: diagnostic.xml

systemProperties:
　　 [echo] Java Runtime Environment version: 
　　　　　　1.4.2_05
　　 [echo] Java Runtime Environment vendor: 
　　　　　　Apple Computer, Inc.
　　 [echo] Java Runtime Environment vendor URL: 
　　　　　　http://apple.com/
　　 ...
　　 [echo] Default temp file path: /tmp
　　 [echo] Operating system name: Mac OS X
　　 [echo] Operating system architecture: ppc
　　 [echo] Operating system version: 10.3.9

　　现在，假如哪个方面出现了问题，你就可以在系统属性中找到问题的源头了，比如错误的Java版本或者类路径等等。

　　文件和类路径的有效性

　　我们可以进一步实现一些自动测试来检测一个文件或类能否被找到：

　　
　　　　　　property="fop.available"/>
　　　　　　property="scriptsdir.exists"/>
　

　　　　unless="fop.available">
　　
　

　　　　depends="files" unless="scriptsdir.exists">
　　
　

　　第一个目标执行两项测试：首先它检查org.apache.fop.apps.Fop类能否在类路径中被找到，然后检查目录directory build/scripts是否存在。将type改为file的话，有效性测试就可以检查指定文件是否存在。假如类或者目录不存在的话，后面两个目标将分别显示出错误信息。

　　Java版本的最低需求

　　我们可以做更多，但是这需要我们编写定制的Ant任务。我们就来检查一下已经安装的Java版本是否高于我们的代码所要求的最低版本。假如版本不符合要求，诊断编译文件就会提示错误信息。JavaVersionTask类的源代码如下：

import org.apache.tools.ant.*;

/**
 JavaVersionTask is an Ant task for testing if
 the installed Java version is greater than a 
 minimum required version.
 **/
public class JavaVersionTask extends Task {

　// Minimum required Java version.
　private String minVersion;
　// Installed Java version.
　private String installedVersion;
　// The name of the property that gets set when
　// the installed Java version is ok.
　private String propertyName;

　/**
　 * ConstrUCtor of the JavaVersionTask class.
　 **/
　public JavaVersionTask() {
　　super();
　　installedVersion = System.getProperty
　　　　　　　　　　　 ("java.version");
　}

　/**
　 * Set the attribute minVersion.
　 **/
　public void setMinVersion(String version) {
　　minVersion = version;
　}

　/**
　 Set the property name that the task sets when
　 the installed Java version is ok.
　 **/
　public void setProperty(String propName) {
　　propertyName = propName;
　}

　/**
　 * Execute the task.
　 **/
　public void execute() throws BuildException {
　　if (propertyName==null) {
　　　throw new BuildException("No property name 
　　　　　　　　　　　　　　　　set.");
　　} else if (minVersion==null) {
　　　throw new BuildException("No minimum version 
　　　　　　　　　　　　　　　　set.");
　　}

　　if(installedVersion.compareTo(minVersion) 
　　　 >= 0) {
　　　getProject().setProperty(propertyName, 
　　　　　　　　　　　　　　　 "true");
　　}
　}
}

　　假如你建立一个定制任务，它的类需要扩展org.apache.tools.ant.Task类。任务的编译文件中每一个属性都使用一个设置方法来设置，方法的名字以“set”开头，接着是属性的名字，名字的首字母需要大写（这是JavaBeans的约定）。例如，属性minVersion使用方法setMinVersion来设置，同样属性property使用方法setProperty来设置。

　　当编译文件调用任务的时候，方法execute将被执行。首先我们检查属性是否已被设置，然后我们执行任务的核心：假如已安装的Java版本高于或者等同于最低要求的Java版本，我们就把指定名字的属性值设为真。

　　版本以字符串对象的形式储存，因此我们可以用按照字母顺序来比较两个字符串的compareTo方法来比较它们。假如第一个串小于第二个串，该方法则返回-1，相等则返回0，假如第一个串按照字母顺序大于第二个串则返回+1。这样任务就可以认为1.5大于1.4，也大于1.4.2或者1.4.2_05。

　　为了在Ant编译文件中使用定制任务，我们首先需要定义一个包含最低所需Java版本的编译属性：

　　在目标systemProperties中我们加入下列代码：

 classname="JavaVersionTask" classpath="."/>
　　property="javaversion.ok"/>

　　第一行定义了一个名叫javaversion的新任务，接着是实现这一任务的Java类名：JavaVersionTask。下一行执行指定了最低所需Java版本的javaversion任务。当已安装的Java版本高于所需版本时，javaversion.ok则被赋值。

　　然后我们加入一个目标javaVersion：

 unless="javaversion.ok">
　　
　

　　接下来，我们把目标加入到目标all的依存关系中。它只有在javaversion.ok属性没有被设置的时候才执行。此时，目标将显示一条错误信息，提示出找到的Java版本和所需的Java版本。这是一个输出的示例：

javaVersion:　　 [echo] ERROR: Java version 
too old: found 1.4.2_05, needs 1.5.

　　与JavaVersionTask相似，我们也可以写一个任务来执行其他的版本检查，例如已安装的库或者操作系统的版本。

　　被改变的文件


　　当问题发生时，了解在安装之后是否有文件被改变是十分重要的。有可能是标准配置被改变或者被替换掉的文件引起了问题。为了调查这一点，我们可以使用Ant的校验和：在我们软件的安装编译文件中，我们为每一个文件生成一个校验和，在诊断测试中我们就可以验证这些校验和。这样我们就可以在安装之后了解哪个文件被改变了，并且该任务缩小了搜索引起问题原因的范围。在安装编译文件中，我们可以为每个可能被改变的重要文件生成一个md5校验和，在诊断编译文件中我们就可以校验它。当然，被改变的二进制文件与被改变的配置文件是有区别的，前者不应该被改变，后者被改变了就可能会引起问题，也可能不会。

　　在我们的安装编译文件中，我们像这样来生成校验和：

　　Ant为build目录及其子目录中所有扩展名为.class的文件生成MD5校验和。校验和将以原文件名保存，加上扩展名.MD5。对于配置文件config.xml也是一样。在所有的文件都被编译之后，目标checksum就将被执行。

　　在诊断编译文件中，我们验证校验和：

　　
　　
　　　
　　　　
　　　　　
　　　　
　　　
　　
　　
　　
　　　
　　


　　 unless="binary.unchanged">
　　
　

　　 unless="config.unchanged">
　　
　

　　将目标加入到目标all的依存关系中。

　　首先，目标checksum将被执行。假如所有类文件的校验和与之前所生成的校验和相符，属性binary.unchanged将被设为真。但假如至少一个文件被改变了，该属性则不会被赋值。然后，假如config.xml文件没有被改变，属性config.unchanged则被设为真。依靠于目标checksum的目标binaryChanged只有在binary.unchanged没有值的时候才被执行，也就是在至少一个类文件被改变的时候，然后将输出一条错误信息。对于配置文件也是一样，但是我们将输出一条警告信息。

　　假如没有文件被改变，我们的诊断编译脚本输出入下信息：

checksum:
　　 [echo] Verifying checksums of binary files...
　　 [echo] Verifying checksum of configuration file...

binaryChanged:

configChanged:

all:

BUILD SUCCESSFUL
Total time: 1 second

　　假设我们改变了配置文件，然后我们会得到这样的输出：

checksum:
　　 [echo] Verifying checksums of binary files...
　　 [echo] Verifying checksum of configuration file...

binaryChanged:

configChanged:
　　 [echo] WARNING: Configuration file changed.

all:

BUILD SUCCESSFUL
Total time: 1 second

　　假如我们的软件开放源代码，我们可以做得更好，甚至可以将被改变的文件恢复成标准版本。对于特定的类文件，这意味着我们需要编译Java文件。当然，你的客户需要拥有完整的JDK（不只是Java运行时）和你的源代码及其编译文件。为了恢复被改变的类文件，我们删除他们然后调用安装编译文件的编译任务。这一任务的细节取决于你的编译系统。

　　作为另外一种选择（例如你的软件为封闭源代码），你可以在安全的位置将已知为正确版本的类文件存放在一个.jar或者.zip文件中并且解包它们。然后你就可以使用已知的正确版本来替换被改变的类文件了。

　　另一方面，配置文件可以从源文件夹中拷贝过来。我们可以适当地扩展目标configChanged并且添加一个目标configRestore来实现这一功能：

 depends="checksum" unless="config.unchanged">
　　
　　　　 and restore original? " validargs="y,n">　　　　　 addproperty="config.restore"/>
　　
　　　
　　
　

　　 depends="configChanged" if="config.copy">
　　
　　　　 tofile="build/config.xml.1" overwrite="true"/>
　　　　 overwrite="true"/>