我一直推崇单元测试，所以我通常认为重构和大规模合并非常不错。如果存在一组单元和/或集成测试，那么就可以在变更过程中确定应用程序是否中断，还可获知问题的所在。因此，我们上周进行了一次大规模程序合，还完成了一些代码清理工作，其中一个应用程序也开始了失败测试。

　　我们通常从测试输出着手来排除故障；然而，本例中却出现一个特殊的问题：由于我们的部分Web服务是单向的，无法提供响应，所以我们必须依靠日志记录和数据库检查来验证一切是否正常。对于这些特别的Web服务，数据库未发生任何变动，我们的日志记录完成了一半。以下是一个中断的Web服务的片断：

@SOAPMessageHandlers( { @SOAPMessageHandler(className = "feedback.util.FeedbackLogHandler") })
public class SoapListener implements ServiceLifecycle {
...
    public void init(Object context) {
        log.debug("init invoked");
        servletEndpointContext = (ServletEndpointContext) context;
    }
...
    @Oneway()
    @WebMethod()
    public void accept(CrashDetail crashDetail) {
        log.debug("accept invoked");

　　初始化过程如期调用，这一点可以在日志中得到验证。处理程序也如期得到调用，我们也在日志中验证了这一点。有趣的是，日志中未出现“accept invoked”。我还是第一次遇到这种情况。

　　控制台上没有错误，应用程序也没有出错，一切正常。这种情况下，必须借助于WSEE的ultra-mega-verbose调试。如果没有强大的机器和高速的IO，最好不要在生产环境中运行它。我使用另外的Dweblogic.wsee.verbose=*标记重新启动了WebLogic。

　　我在更改之前部署了一个EAR，以了解WSEE输出的情况，随后运行测试并且部署了一个“已中断”版本的EAR。WSEE显示如下：

<WSEE>Processing AuthorizationHandler...  <HandlerIterator.handleRequest:118>
<WSEE>Processing ContainerHandler...  <HandlerIterator.handleRequest:118>
<WSEE>Failed to invoke handler<HandlerIterator.handleRequest:141>
<WSEE>weblogic.wsee.jws.container.InvokeException: Unable to Load JWS<HandlerIterator.handleRequest:141>
weblogic.wsee.jws.container.InvokeException: Unable to Load JWS
        at weblogic.wsee.jws.container.Container.init(Container.java:135)
        at weblogic.wsee.jws.container.Container.<init>(Container.java:79)
        at weblogic.wsee.jws.container.ContainerFactory.createContainer(ContainerFactory.java:51)

　　坦白地说，这没什么用。这种情况我也是第一次遇到：通常当我在Web服务中碰到意外情况时，打开WSEE调试很快就可以发现问题——以最快地速度搜索几千行调试输出。

　　最后，我分开了正常和不良的EAR，通过比较所有文件发现了问题。我发现weblogic-application.xml 文件在最近的一次程序合并过程中丢失了weblogic-controls-1.0库。有趣的是，由于在构建过程中不需要使用该库，因此我可以正常地构建和导出。在运行时，我没有发现任何错误——可能是因为我的服务是单向的。

　　希望我为服务排除故障的这些步骤对大家有所帮助。

原文出处：http://dev2dev.bea.com/blog/jerjohns/archive/2007/02/merge_problem_c.html