Sonar的安装很容易，按照Sonar官方主页的安装指南解压缩即可。

Sonar默认使用derby作为数据库，你只需要在sonar.properties文件中去掉对derby数据库属性的注释，然后启动Apache derby数据库。

按照文档介绍，启动Sonar，默认的主页地址是http://localhost:9000，登录用户名和密码是sonar/sonar。

使用Sonar检查代码：

要使用Sonar检查代码，也很容易。

如果待检查项目是maven项目，则只需要安装sonar maven plugin即可；如果是非maven项目，则需要在项目根目录下创建pom.xml，内容按照文档配置。具体参 见：http://docs.codehaus.org/display/SONAR/Analyzing+Java+Projects

现在只需要项目根目录下，运行mvn sonar:sonar就可以运行sonar maven plugin来检查项目中的代码了。

注意：

如果项目源文件使用的编码与系统的默认字符集不同，比如操作系统是GBK，而源文件编码为UTF-8。为了能够正常地检查代码，需要在pom.xml的properties元素下增加一项配置如:

否则，sonar在生成checkstyle.xml的时候，不会将正确的编码传进去，导致checkstyle在做AST分析的过程中使用了错误 的字符集，从而提示字符错误：“expecting 'xxx', but got '<EOF>'”。即使是在调用mvn sonar:sonar的时候，增加参数如：

mvn -Dfile.encoding=UTF-8 -DsourceEncoding=UTF-8 sonar:sonar

也无法生效，虽然通过-e开关是可以看到系统的默认字符集已经改成了UTF-8。

好了，sonar已经安装完毕，而且也顺利地完成了代码的分析和检查。

下一步，我们就可以分析sonar输出的报告，判断代码的质量，制定改善的措施了。

前一阵子使用JSF开发web应用程序的过程中，碰到一个需求：A页面上存在一个链接，用户点击链接会被重定向B页面。页面B上存在一个单选框，如果是通过A页面的链接过来，会把单选框置为“选择”的状态。这是非常典型的页面转向，根据JSF的页面转向配置，以及对JSF隐含对象param的介绍，下面的代码“貌似”可行：

A页面：

<h:commandLink value="Add" action="add">
  <f:param name="type" value="student" />
</h:commandLink>

B页面：

<h:form>
  <h:selectOneRadio id="type" value="#{param.type}">
    <f:selectItem itemlabel="student" itemvalue="student" />
    <f:selectItem itemlabel="teacher" itemvalue="teacher" />
  </h:selectOneRadio>
  <h:commandButton id="add" action="#{backingBean.add}" />
</h:form>

编译、部署、重新刷新页面。不错，B页面上单选框的状态能根据是否来自A页面的链接呈现选中或否的状态：一切看上去都很美，似乎已经完成了功能开发。但是，等等，让我们提交表单。浏览器刷新了一遍，又回到了这个页面。通过检查后台数据库以及日志文件，我们发现：

• 数据库里面并没有添加新的记录
• 系统也没有按照配置的navigation转向正确的页面
• glassfish的日志文件中没有add方法执行打印的日志，也没有任何异常信息

原则

在软件开发中，调试的目的是解决“如何定位系统问题所在”的问题。一般意义上，解决问题的原则，套用胡适先生的话，就是“大胆假设，小心求证”；套用《麦肯锡方法》，则是“以事实为基础，以假设为导向，结构化推理”。具体来看，调试是这样一种分析问题的方法，面对复杂的问题，通过逐步确定正确或者错误的事情，缩小问题范围，直到定位问题所在为止。把事情确定化，也可以细分为以下步骤：

• 提出猜想
• 验证猜想 or 捕获异常
• 提出新的猜想

• 技术层面
• 业务层面

• 划定问题域边界
• 选择确定的出发点
• 借助其他已经确定的点走查问题域，缩小问题域

步骤

我们先来划定我们初始的问题域：JSF请求提交后，JSF不能正常调用后台方法进行处理。我们想知道，JSF处理请求过程中哪个地方出问题了。那么我们确定的点是什么呢？JSF规范。因为我们使用的是SUN开发的JSF RI，所以它必然满足JSF规范。在规范中，JSF的请求处理过程一共分成六个阶段：

1. Restore View
2. Apply Request Values
3. Process Validations
4. Update Model Values
5. Invoke Application
6. Render Response

我们可以定义一个PhaseListener，注册到faces-configs.xml文件里面，看整个请求过程发生了什么？通过查看 glassfish的日志文件，我们发现update model values之后就直接render response，没有 invoke application。 如果一切正常，应该是从第一步执行到第六步，但现在跳过了第五步，直接从第四步到了第六步，是哪里出现了问题？好，从“JSF的处理过程”到“第四步 Update Model Values”，我们已经缩小了问题域的范围，现在确定的点已经有JSF规范和 “Update Model Values”了。继续，从JSF规范对步骤“”中寻找“Update Model Values”的说明：

If any of the updateModel() methods that was invoked, or an event listener that processed a queued event, called renderResponse() on the FacesContext instance for the current request, clear the remaining events from the event queue and transfer control to the Render Response phase of the request processing lifecycle. Otherwise, control must proceed to the Invoke Application phase.

这里提到如果我们在updateModel()方法或者事件监听器里面调用了FacesContext的renderResponse()方法，就会从事件队列里面直接清空剩下的事件，转向Render Response步骤。但是我们没有注册任何的事件监听器，也没有自定义任何组件的 updateModel()方法，那就只能是在系统组件的updateModel()方法里面抛出异常被JSF引擎捕获，然后直接 render response。现在进一步缩小范围了，让我们来看看Javaapi doc里面是如何介绍UIInput.updateModel() 方法的。

Call setValue() method of the ValueExpression to update the value that the ValueExpression points at.

问题转移到javax.el.ValueExpression的setValue()方法，我们来看看这个方法的API：

Evaluates the expression relative to the provided context, and sets the result to the provided value.
Throws:
PropertyNotFoundException - if one of the property resolutions failed because a specified variable or property does not exist or is not readable.

再来看看组件的ValueExpression，我们写的是“${param.key}”，从文档里面可以得知param就是 externalContext.getRequestParameterMap()，而 ExternalContext.getRequestParameterMap()的文档描写是这样的：

Return an immutable Map whose keys are the set of request parameters names included in the current request, and whose values (of type String) are the first (or only) value for each parameter name returned by the underlying request.

因为表单提交时的request跟之前页面转向时的Request肯定不是一样，那是否由于该ValueExpression导致的问题。让我们来验证一下，把B页面上单选框组件的值改成字符串字面值“student”。现在B页面的单选框组件就变成了：

部署，运行。不错，现在的页面组件能保持选中的状态，也能顺利创建新纪录，日志文件中也有add方式的执行信息：说明的确是因为#{param.key} 表达式的求值出错导致异常。这里的#{param}已经不再是上一步的#{param}，自然无法从externalContext的 RequestParameterMap里面找到参数名为type的值。因此，JSF运行到这里，因为无法取到参数值去更新页面的单选框组件，所以就跳出了处理过程。

现在，回过头来看一下问题的原因：JSF在处理请求的时候，会对页面组件树上的所有组件进行递归更新，它会根据组件定义的EL表达式来重新计算值，更新组件状态，以保证JSF页面组件的状态性。我们得到的教训是param等JSF隐含对象或许能用，但最好不要放在JSF组件里面。“进什么庙，拜什么神”，我们还是选择JSF推荐的backingbean来保持组件的值。

结语

软件调试是一项很有意思的活动，常常给开发人员带来解谜般的快感，或者一团乱麻的纠结。导入代码、设置断点、逐步调试并不是最好的办法，清楚地划分问题域，找准确定点可能会事半功倍。当然，在找出水面下面的暗礁之后，别忘记给自己、给其他人mark上这块区域的暗礁位置，能极大减少以后触礁的痛苦。