将遗留Web应用程序移植到NetBeans

简介

许多有关在 NetBeans 中处理项目的文章和书籍一开始都假定您正在从头开发项目。本文讨论的是：假如您已经获得了一个现有的 Web 应用程序、并希望对它进行转换以便使用 NetBeans 作为开发和部署工具时所需的步骤。

本文中所介绍的步骤是我过去将现有 Web 应用程序移植到 NetBeans 5.0 IDE 时使用的。该应用程序十分具有代表性，在这个应用程序中，它使用 Java 服务器页面、Jakarta Struts 和 JDBC 将数据存储到相关数据库中。这个过程非常复杂，因为它还使用了 Spring 应用程序框架和 Open Symphony 对象缓存来增强性能。

移动的原因

如果Web 应用程序已经存在且正在运行，您可能想知道为什么要决定将它移动到 NetBeans IDE 框架中呢。答案就是 NetBeans 提供了某些独特的优点，这些优点使得它极具吸引力。

首先，NetBeans 提供了一个统一的开发环境并从根本上了解 Java 和 Web 应用程序的要求。这就意味着使用 NetBeans 将会对开发和部署 Web 应用程序带来极大的帮助。

其次，由于许多人员已经熟悉了 NetBeans IDE，寻找有能力对 Web 应用程序进行增强的工程师相对比较容易。

第三，NetBeans 为自动化和一次性单元测试提供了一个更加一体化的模型。在开发 Web 应用程序时，单元测试并不是最重要的工作，但随着对更新和更复杂功能的开发，单元测试立即就变成一项十分重要的工作。

最后，由于在为 Web 应用程序开发更新和更复杂的功能时，通过代码完成、语法检查和快速文档工具的帮助可以使开发新代码的工作变得更容易且更有效。

进攻计划

在本文的这一部分，我会向您介绍我将遗留 Web 应用程序移植到 NetBeans 5.0 环境时使用的所有步骤。我将讨论应在移植前执行的步骤、移植应用程序的过程、对移植是否成功进行验证。

遗留软件的审计

我所执行的第一个步骤是确保我完全了解现有的应用程序。该步骤涉及源代码的检查、开发、测试和运行环境、以及构建流程。

在这个阶段，设计注释或开发注释形式的良好文档非常有用。访问现有代码的一个或多个开发人员也很有帮助。在我的例子中，我没有那么幸运，我不得不自己通过阅读代码库本身来理解。

构建现有 Web 应用程序

这一步非常重要。确保您了解如何使用现有的构建方法构建当前的 Web 应用程序。这将能够快速发现所缺少的代码段或者在将此代码库移动到 NetBeans 时需要了解的其它依存关系。

在我的例子中，我构建了 Web 应用程序并将它安装在我的测试应用程序服务器中。当我开始运行应用程序时，却出现了一系列没有道理的 JDBC 错误。我马上打电话询问，原来是我所给出的数据库导出的一个升级修改了数据库架构。我获得了该升级并对数据库应用之后，Web 应用程序显示了我所预期的结果。

检查源代码

由于我没有对任何设计或工程文档的访问权限，所以我需要通过阅读代码开始对其进行了解。因为我要阅读源代码，我决定通过在每个文件中查找多个问题来充分利用我的时间。这些问题包括：

1. 此文件用来做什么？如果它是一个类，其目的是什么？
2. 内嵌文档与代码的匹配情况怎样？对代码的注释是否足以清楚地说明代码的目的？
3. 代码有哪些依存关系？它们的形式或者是界面或者是库。
4. 此文件有相关的测试程序吗？

我强烈建议您在此阶段对对象进行注释或拟出草图，以便您大致了解每个对象的作用并了解它们之间的各种关系。用来捕获这些注释的工具由您自行选择。我喜欢使用 UML 图标工具，因为我以后可以继续使用该工具计划对应用程序的增强。

库

记录此 Web 应用程序所依赖的任何库（jar 文件）也很有用。此列表可以通过在构建流程中查找所有引用的 jar 文件生成，也可以通过在您所给出的代码库中查找所有 jar 文件生成，还可以通过在代码中引用所有 Java 导入语句生成。

在我的例子中，我通过在代码库中查找所有 jar 文件获得库列表。以下是针对我的 Web 应用程序的列表：

库文件

描述

版本

classes12

Oracle JDBC 驱动程序

9.0.2.0.0

commons-beanutils

Jakarta Commons Beanutils

1.6

commons-collections

Jakarta Commons Collections

3.1

commons-dbcp

Jakarta Commons Database Connection Pooling

1.1

commons-digester

Jakarta Commons Digester

1.5

commons-fileupload

用于 Java servlets 的 Jakarta 文件上载组件

1.0

commons-lang

Jakarta Commons Lang

1.0.1

commons-logging

Jakarta Commons Logging

1.0.3

commons-pool

Jakarta Commons Object Pooling Library

1.1

commons.validator

Jakarta Commons Validator

1.0.2

jakarta-oro

Jakarta Oro

1.0

JUnit

Java 单元测试框架

3.8.1

log4j

Logging Framework

1.2.8

mysql-connector-java

MySQL JDBC 驱动程序

3.0.11

oscache

Open Symphony 对象缓存

2.1

spring

Spring 应用程序框架

1.0.2

struts

Java 应用程序框架

1.1

struts-legacy

Java 应用程序框架

1.0

 

在浏览器中快速检查后发现，这些库中有许多都不是最新的；但我决定不将升级库作为移植练习的一部分。而是决定在代码库移动到 NetBeans 之后，将更新库作为首要任务之一。人们总是想尝试一次解决太多问题，这样反而会使诊断一个无法预料的问题更加困难。我迫使自己只针对到 NetBeans 的移植进行必要的更改，从而降低了移植过程中的复杂性。

我立刻就注意到，Web 应用程序具有用于 Oracle 和 MySQL 的 JDBC 驱动程序。通过快速检查代码，我发现以前的开发人员使用了 MySQL 进行测试，并使用 Oracle 生产 War 图像。

我设置了一个任务列表，以记录代码移动到 NetBeans 环境之后我要执行的活动；“更新库”就被添加到了该列表中。

目标 Web 应用程序服务器

NetBeans 具有各种支持不同 Web 应用程序服务器的资源包配置。其中包括 Jakarta TomCat、Sun Java EE、J2EE 应用程序服务器，以及很快就要添加的 JBoss。通过下载这些预配置的 Web 服务器资源包，您可以节省相当多的时间。

因为我知道此应用程序将要在 Sun Java EE Web Server 环境中运行，所以我决定下载并安装 NetBeans Enterprise Pack 资源包，它包含了许多在 Java EE 环境中使用的功能。

源控制系统

我特别惊奇地发现，由于 Web 应用程序已经运行了多年的生产环境，我给出的源代码没有被放置到任何形式的源控制下。于是，我将“将代码放置到源代码控制下”添加到了移植后任务列表。

如果 Web 应用程序已经使用了某种形式的源控制系统，我将不得不决定如何处理到 NetBeans 的移植，因为各种文件和目录在移植过程中将会被重新安排。主要问题是：有没有必要从新 NetBeans 环境中的遗留应用程序维护修订控制信息。维护这种移动的更改历史纪录非常困难，而且我们应当清醒地认识到它有可能需要花费很多时间和经验才能得到正确的结果。

NetBeans 5.0 在 IDE 中为 CVS 提供了支持，而且 NetBeans 5.5 还将添加 SVN 支持。还有一个插件可以用来支持 OpenVMS CMS。

内部文档

考虑到我必须要检查源代码，我认为这是确定代码在内部记录情况是否良好的最佳时机。这一点特别重要，因为我没有任何可以参考的设计或开发注释。幸运的是，代码使用 Javadoc 指令记录得相当好，尽管我也发现了由于代码的剪切和粘贴而在文档中引入了一些人为错误。这通常表现为在当前的文档中将以前的代码块重复用作 Javadoc 块。我将“修复内部文档”添加到了我的任务列表中。

在内部方法本身的记录方面代码显得比较差。有一种思想流派认为，代码编写应当尽量简洁，几乎不需要方法内部的文档。虽然我同意这种看法是一种比较理想情况，但我发现代码很少采用这种方法进行编写，所以我的观点是方法内部的文档是首选的。

在 NetBeans 中创建 Web 项目

现在，我准备在 NetBeans 中创建一个空白的 Web 应用程序项目。我从菜单中选择 File | New Project，然后从 New Project 对话屏幕中选择Web | Web Application。

按下 Next 按钮，将会出现 New Web Application 对话框。我输入我的 Project Name 和 Project Location 值，然后选择我的 Source Structure。

Source Structure 选择器几乎不需要解释。Web 应用程序有两种主要的标准布局：Jakarta 和 Java BluePrints。

高亮显示的区域显示了两种标准之间的差异。对于 J2EE 环境强烈建议使用 Java BluePrint，所以我选择了它。

因为我希望在不影响其他用户的情况下测试我的代码库移植，所以我选择使用绑定的 TomCat 服务器，它来自于我的 NetBeans 5.0 副本。我设置了相应的 Context Path，并将两个复选框保留为选中状态。我将确保在对其他工程师发布代码之前，使用 Java Web Server 产品执行最终测试。

导入应用程序

现在我的任务是将现有的所有源代码移动到新的 Web 应用程序项目目录。以下是我所执行的步骤：

1. 将 Java 源代码（包括各种包所需要的所有目录）放置到 src/java 目录下。
2. 将 Java 源代码所需要的 Java 属性文件也放置到 src/java 目录中。
3. 将单元测试程序放置在测试目录中。
4. 将图形图像放置在 Web 目录中一个名为“images”的目录中。
5. 由于此应用程序是基于 Struts 的，我将 index.jsp 文件也放置到 Web 目录中，并包含了一个指向 struts 起始页面的重定向指令。
6. WEB-INF 目录包含了所有 Struts 配置 XML 文件、JDBC 属性文件和缓存控制属性文件。
7. WEB-INF 目录还包含名为“jsp”、“lib”和“tld’”的目录，以保存由 Struts 和 OSCache Frameworks 使用的 Java 服务器页面、Java JAR 文件和标记库定义。

最终的布局如下所示：

修改 build.xml 文件

在了解如何使用现有构建方法构建现有 Web 应用程序的过程中，我幸运地发现：构建流程是以 Jakarta Ant 程序为基础的，但是，当我打开与 Ant 构建相关联的 build.xml 时，我发现文件中有许多额外的 Ant目标。

检查这些额外构建文件后发现，最初的开发人员将执行数据库更新/回滚的机制作为了构建指令文件的一部分。我不知道促使他采用这种方式的原因，我自己更喜欢有一个独立的文件（即：database_upgrade.xml），以一种与主要构建文件隔离的方式来处理此任务。在需要时，它始终可以作为“ant –f database_upgrade.xml”调用。

我正在处理的数据库已经升级，所以我决定从构建集中删除这些 Ant 目标。

构建流程还使用一个外部构建属性文件（build.properties）来定义数据库连接和会话超时的详细信息。我对这些进行了调整，以反映我的测试环境。

第一次构建

按照上面显示的目录结构将所有源文件复制到正确的位置之后，就可以尝试第一次构建 Web 应用程序了。为了执行此操作，我从 NetBeans 菜单栏中选择 Build | Build Main Project。

构建流程进展十分顺利，将所有 Java 源代码编译为类文件，将所有文件复制到 build/Web 目录，然后生成分布在“dist”目录中的 War 文件。

此时也是检查能否为此代码生成相应 Javadoc 的大好时机。我从 NetBeans 菜单中选择 Build | Generate Javadoc for Project。生成了 Javadoc 并放置在“dist”目录中。浏览器也被启动，显示文档集的主索引页面。

测试 Web 应用程序

因为我准备首先秘密测试 Web 应用程序，所以我在 NetBeans 菜单栏中选择 Run | Run Main Project。这样，NetBeans 就使用了我在 Tools | Server Manager 管理表单中指定的默认应用程序服务器。构建操作中创建的 War 文件被复制到 Web 应用程序服务器文件结构中的合适位置，然后，Web 服务器对文件进行解压缩。这时打开了一个 Web 浏览器窗口，显示在 Web 应用程序服务器中运行的 Web 应用程序。

因为在生产服务器上已经运行了一个 Web 应用程序的活动实例，所以我可以在本地副本和生产副本之间执行并行比较测试。