从 WebSphere Studio Classic 迁移到 IBM WebSphere Studio Site Developer
第 1 章 WebSphere Application Server - Express 迁移指南概述
第 3 章 从 IBM WebSphere Studio Site Developer V5.1 进行迁移
第 4 章 从 IBM WebSphere Studio Site Developer V5 或 V5.0.1 进行迁移
第 5 章 从 IBM WebSphere Studio Site Developer V4.0.x 进行迁移
第 6 章 从 WebSphere Studio "Classic" 迁移到 IBM WebSphere Studio Site Developer
第 7 章 从 VisualAge for Java 迁移到 IBM WebSphere Studio Site Developer
第 8 章 从 VisualAge for Java 可视化组合编辑器迁移到 Visual Editor for Java
第 9 章 构建设置（库、JAR、从属项目 JAR 和 Ant 构建）
在此版本的 IBM(R) WebSphere(R)Application Server - Express V5.1 中，可以从下列产品迁移代码：
WebSphere Application Server - Express 5.1 由 WebSphere Application Server 5.1 和 WebSphere Studio Site Developer 5.1.1 组成。下面的第一章讲述了 WebSphere Application Server - Express 的服务器功能部件的迁移。本《迁移指南》的其余部分主要讲述从不同版本的 WebSphere Studio Site Developer 迁移代码。
与迁移服务器有关的重要注释：
仅当使用“管理控制台”来管理服务器（通常在生产环境中）时迁移服务器配置才有意义。在此方式的操作中，服务器配置和已部署的应用程序存储在服务器的 config 目录中。迁移过程将为您迁移这些配置和应用程序文件。另外，如果要使用 WebSphere Studio Site Developer 来配置应用程序并将应用程序部署到远程服务器，则不需要迁移服务器配置文件。这是因为配置和应用程序文件都保留在 Studio Site Developer 工作空间中。工作空间将由 Studio Site Developer 迁移。然后可以定义一个 WebSphere Application Server - Express 5.1 服务器的新实例，并继续从 Studio Site Developer 配置和部署应用程序。
本指南分为以下几章：
从 WebSphere Studio Classic 迁移到 IBM WebSphere Studio Site Developer
有关使用 WebSphere Application Server - Express 的信息，可以在《入门》指南和联机帮助中找到。在安装 WebSphere Application Server - Express 之前，请阅读《安装指南》。成功安装 WebSphere Application Server - Express 之后，请阅读《入门》指南并完成《入门》教程。该教程将向您介绍工作台、Java(TM) 开发和 Web 服务。在完成该教程之后，请阅读本指南以便将应用程序资源迁移到 WebSphere Application Server - Express 中。
在 /readme 目录中有本指南的 HTML 和 Acrobat PDF 版本。两个版本包含完全相同的信息。可以在任何 Web 浏览器中打开 migrate.html。要打开 migrate.pdf，必须安装 Acrobat Reader 软件，可以从 www.adobe.com/products/acrobat/readstep2.html 下载该软件。
本《迁移指南》自始至终都使用 Windows(R) 约定。例如，Windows 中的“WS_Installdir\”相当于 Linux 中的“WS_Installdir/”。
有关本指南将来的更新，参阅 www.ibm.com/websphere/developer/zones/studio/transition.html。
迁移是利用现有资源的一项活动。迁移任务和工具帮助您升级产品及其先决条件、合理地重用现有应用程序组件以及将管理配置从先前版本转移至当前版本。
迁移 WebSphere Application Server 产品时将利用现有环境和应用程序，并将它们更改为与当前产品版本兼容。
产品迁移功能是由 IBM WebSphere Application Server - Express V5.1 中的迁移工具提供的。这些迁移工具支持从下列产品进行迁移：
产品安装向导将检测 IBM WebSphere Application Server - Express 的先前版本，并在安装版本 5.1 期间允许您选择运行迁移工具。要从 IBM WebSphere Application Server V3.5 进行迁移，必须直接运行这些工具。
迁移红皮书
从红皮书 Web 站点（网址为：http://www.ibm.com/redbooks）可获得 Migrating to WebSphere V5: An End-to-End Migration Guide。要找到红皮书，可搜索文档号 SG24-6910-00。与本文相比，红皮书提供了更全面的介绍，包括有关应用程序迁移的更详细的计划信息以及 WebSphere Studio Application Developer 工具和样本。
版本 3.5 迁移：移至 J2EE 模型
V3.5.x 用户升级到版本 5 时将移至一个基于 J2EE 规范的平台。J2EE 技术将应用程序的开发和创建与应用程序管理、部署和管理明确地分开。从版本 3.5 进行迁移将涉及到应用程序结构、开发和部署的更改。
迁移工具通过迁移系统配置和创建 J2EE 构件（包括 J2EE 安全角色映射）来帮助从版本 3.5.x 转换为版本 5。迁移工具根据版本 3.5.x 配置来创建初始 J2EE 企业应用程序。但是，由于应用程序结构发生了重大更改，因此，需要使用开发和部署工具来仔细测试和调整已迁移的应用程序，以准确地确定应用程序在新环境中如何工作。
J2EE 模型使您能够独立于应用程序的最终部署环境来开发应用程序。这种将任务分开处理的方法简化了将应用程序从初始开发提升到生产或者将应用程序从一个服务器移至另一个服务器的过程。目的是只更改应用程序部署参数，而不更改应用程序代码。
在开始之前，请确定在计划安装版本 5.1 产品的机器上是否安装了 WebSphere Application Server 的现有版本。如果安装了先前版本，则必须计划是否将先前版本的配置和应用程序复制到新版本中，也就是进行迁移。进行迁移不会卸载先前版本。先前的发行版仍然起作用。如果在安装版本 5.1 时运行先前发行版，则这两个版本将共存。要同时运行这两个版本，必须配置端口以便使这两个版本不发生冲突。注意，迁移操作只是按原样迁移端口定义，因此，在这两个版本中端口定义是相同的。WebSphere Application Server 包含提供了所有迁移功能的迁移工具。安装向导可以调用迁移工具，您也可以稍后手工调用它们。
总之，从 IBM WebSphere Application Server - Express V5.0.x 迁移到 V5.1 是相当常见的工作。可以使用安装程序来进行迁移，并且迁移之后只需要执行少量调整或者不需要执行调整。也可以手工使用迁移工具来保存版本 5.0.0、版本 5.0.1 或版本 5.0.2 配置数据，卸载版本 5.0.0、版本 5.0.1 或版本 5.0.2，然后安装版本 5.1 ，并再次使用迁移工具来复原配置数据。
总之，从 IBM WebSphere Application Server V3.5 迁移到 IBM WebSphere Application Server - Express V5.1 涉及到应用程序结构、开发和部署的重大更改。迁移工具通过迁移系统配置和创建 J2EE 构件（包括将先前的安全设置映射至 J2EE 安全角色）来帮助完成此转换。这些安全映射允许您在转换期间访问已迁移的资源。迁移工具根据版本 3.5.x 配置来创建初始 J2EE 企业应用程序。但是，由于应用程序结构发生了重大更改，因此，应使用开发和部署工具来仔细测试和精确调整已迁移的应用程序。
迁移将下列文件保存在 backup 目录中。
此主题介绍了 WebSphere Application Server 提供的迁移工具。所有迁移工具都是在产品 CD-ROM 上的 /migration 目录中提供的。对要安装的 Application Server 版本使用迁移工具是非常重要的。这些工具经过一段时间之后将发生更改。产品 CD-ROM 上的工具提供了从 Application Server 的前发行版迁移到产品 CD-ROM 上的一个发行版所必需的功能。CD-ROM 上的工具与 CD-ROM 上的产品是相匹配的。如果使用 Application Server 的先前发行版中的迁移工具，则迁移过程中可能会遇到问题。
WASPreUpgrade.sh（或 WASPreUpgrade.bat）脚本是用于将先前版本或发行版的配置和应用程序迁移至 Application Server - Express V5.1 的迁移工具。
安装之后，命令文件位于安装根目录的 AppServer/bin 子目录中。也可以直接从 CD 上的 migration 子目录中获得它。
语法
WASPreUpgrade backupDirectory currentWASDirectory
[adminNodeName]
[-nameServiceHost host_name [-nameServicePort port_number ]]
[-traceString trace_spec [-traceFile file_name ]]
参数
前两个自变量是必需的并且位置是固定的。
受支持的自变量包括：
Logging
WASPreUpgrade 工具在运行时将状态显示到屏幕上。它还会将更多的记录信息保存在 backup 目录中。可以使用文本编辑器来查看 WASPreUpgrade.log 文件。
WASPostUpgrade.sh（或 WASPostUpgrade.bat）脚本是用于将先前版本或发行版的配置和应用程序迁移至 Application Server - Express V5.1 的迁移工具。
命令文件位于安装根目录的 AppServer/bin 目录中。
对于版本 5.1 安装，WASPostUpgrade 工具将所有已迁移的应用程序都安装到 AppServer/installedApps 目录中。此工具包括 WASPreUpgrade 工具创建的备份目录中的应用程序。WASPreUpgrade 工具从 installedApps 目录或先前版本或发行版中的其它目录复制应用程序。
语法
WASPostUpgrade backupDirectory
[-serverName server_name]
[-webModuleAdditionalClasspath classpath]
[-documentRootLimit number]
[-substitute "key1=value1[;key2=value2;[...]]"]
[-portBlock port_starting_number]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString trace_spec [-traceFile file_name]]
参数
第一个自变量是必需的。受支持的自变量包括：
在输入 XML 数据文件中，以 $key$ 形式显示的每个键都表示要替换。在输入 XML 文件中，此自变量将把出现的任何 $NODE_NAME$ 替换为 admin_node，而将 $APP_SERVER$ 替换为 default_server。
如果替换字符串中包含分号，则使用 $semiColon$ 来将它与“;”定界符区分开。在 UNIX 平台上，对替换字符串中的每个美元符号（$）添加一个转义字符（例如，\$semiColon\$）。
此参数适用于 Advanced Edition V3.5.x 中保存的配置。
Logging
WASPostUpgrade 工具在运行时将状态显示到屏幕上。它还会将更多的记录信息保存在 logs 目录中。可以使用文本编辑器来查看 WASPostUpgrade.log 文件。
本主题描述迁移期间将进行哪些更改，哪些始终将涉及到单台机器，例如，单机上的开发环境。
分析 WASPostUpgrade.log 文件以了解有关已迁移的企业 bean 的详细信息。J2EE 编程模型指定如何创建和部署应用程序的体系结构。因为版本 3.5.x 中的应用程序没有相同的体系结构，所以 WASPostUpgrade 工具将重新创建应用程序。它在 J2EE 应用程序中创建所有已迁移的 Web 资源和企业 bean。它将所有企业应用程序以相同名称从版本 3.5.x 安装映射至 J2EE 应用程序，并部署在同一服务器上。
WASPostUpgrade 工具将未包含在企业应用程序中的 Web 资源映射至包含服务器名称的缺省 J2EE 应用程序。此工具将 Web 应用程序映射至 J2EE WAR 文件。此工具将资源组合在 J2EE EAR 文件中，并将它部署在版本 5 配置中。
可以使用版本 3.5.x datasources.xml 文件来扩充数据源配置设置。V3.5.x 将文件存储在 properties 目录中。迁移工具通过将文件中的属性合并到数据源和 JDBC 驱动程序配置中来迁移现有 datasources.xml 文件。
V3.5.x 企业应用程序条目是可选的，它们通常用来为安全性定义将多组对象组织在一起。企业 bean 和企业应用程序的 Web 应用程序部分指向它们在 XML 文件的其它部分中的相应条目。处理每个企业应用程序来以相同名称创建 J2EE 应用程序。企业 bean 和 Web 应用程序条目用作指向企业 bean 和 Web 应用程序的定义的指针。然后，这些条目的详细信息用来构建 J2EE 应用程序。
对于企业 bean 文件，JAR 文件定义用来查找要重新部署并添加至 J2EE 应用程序的 JAR 文件。Web 应用程序文档根条目用来查找 Web 应用程序中使用的资源（HTML 和 JSP 页等等）。这些文件将被复制到 J2EE 应用程序中的 WAR 文件。Web 应用程序的类路径条目用来查找复制到 J2EE 应用程序中的 WAR 文件的 servlet 和 JAR 文件。
在从版本 3.5.x 迁移期间会创建企业应用程序。它们是作为与 J2EE 1.2 兼容的企业应用程序创建的，它们包含 servlet 2.2 级别和 JSP 1.1 级别的模块。这提供了最直接的正向兼容性，并启用了与先前 WebSphere Application Server 版本的互操作性。
在版本 3.5.x 中，安全授权模型基于“企业应用程序”和“方法组”概念。企业应用程序与方法组的交叉产品是 WebSphere Application Server 许可权。J2EE 规范包括基于角色的授权模型。
要从 WebSphere Application Server 许可权模型版本 3.5.x 转换为版本 5 的基于角色的授权模型，迁移工具将创建 WebSphere Application Server 许可权与该应用程序的新角色之间的一一映射。因此，对于版本 3.5.x 中的每个企业应用程序和方法组，迁移工具将在版本 5 中创建一个包含在 J2EE 应用程序部署描述符中的角色。每个角色的授权主题都包含于在可以在 J2EE 应用程序绑定中找到的授权表中。
J2EE 规范包括基于角色的授权模型。WebSphere Application Server 解释角色意味着通过一组许可权来访问资源。在进行企业 bean 方法调用的情况下，用于访问特定 bean 上的方法的许可权是由方法许可权指定的。此方法许可权与 bean JAR 文件中的部署描述符中的一个或多个角色相关联。
在访问 Web 资源时，访问 Web URI 和对该 URI 调用 HTTP 方法的许可权是根据 J2EE 规范中的 Web 资源集合和安全约束来指定的。Web 应用程序 WAR 文件的部署描述符包含安全约束和 Web 资源集合。
版本 5 象运行 JSP 1.2 对象一样运行 JSP 1.0 和 1.1 对象，这是唯一受支持的级别。
版本 5 不支持先前版本的 Servlet 重定向器。迁移工具将忽略这些对象。
如果版本 3.5.x 配置定义了 SimpleFileServlet servlet，则不会迁移 servlet。迁移工具在 ibm-web-ext.xmi Web 模块文件中将 FileServingEnabled 属性设置为 true。
如果版本 3.5 配置定义了 InvokerServlet servlet，则不会迁移 servlet。迁移工具在 ibm-web-ext.xml Web 模块文件中将 ServeServletsByClassnameEnabled 属性设置为 true。
如果版本 3.5.x 配置定义了 DefaultErrorReporter servlet，则会将 servlet 迁移到 web.xml Web 模块文件中。迁移使用新包来设置类名。
在版本 3.5.x 中，“servlet 引擎”的缺省传输类型为“打开 servlet 引擎”（OSE）。因为版本 5 不再支持 OSE 传输，所以迁移工具使用相同的端口赋值将这些传输映射至 HTTP 传输。必须为每个端口手工添加 VirtualHost 别名条目。
正如此任务所述，可以使用安装向导来迁移管理配置，也可以手工迁移。如果决定手工迁移，则不要选择安装向导迁移面板上的迁移复选框。
如果使用 WebSphere Application Server 的先前版本，则系统管理员可能具有适用于您的环境的精确调整的各种应用程序和服务器设置。需要具有一种策略能够以最高的效率和最低的损失来迁移这些设置，这是很重要的。
可以通过多次调用迁移工具并且每次指定不同的配置文件来执行增量手工迁移。使用多个配置文件是有多种原因的。无论是何种原因，一次迁移一个配置文件使您在继续迁移下一个配置文件之前能够以增量方式测试应用程序。
在使用迁移工具之前，参阅《V5.x 发行说明》文档以便了解必须对先前版本应用哪些修订。将修订应用于先前版本时可能还会将修订应用于在迁移中具有角色的文件。应用任何修订以确保尽可能最有效地迁移配置和应用程序。
与安装向导提供的完整迁移相比，手工迁移提供了一种增量迁移方法。IBM 提供了一组迁移工具来将管理配置从版本 3.5.x 或版本 5.0.x 的任何版本迁移至 WebSphere Application Server - Express 产品。整个迁移过程就是：使用 WASPreUpgrade 迁移工具来备份当前配置和必需的文件，卸载先前的发行版，在不选择自动迁移选项的情况下安装版本 5 产品，使用 WASPostUpgrade 迁移工具从先前发行版中复原配置。
选择这些迁移方案中的任何迁移方案，以获取有关如何将配置数据迁移至基本 WebSphere Application Server 节点的信息：
可以使用迁移工具来将 WebSphere Application Server V3.5 的配置数据迁移至 WebSphere Application Server - Express V5.1。
通常，将使用 WebSphere Application Server V5.1 中的 WASPreUpgrade 和 WASPostUpgrade 迁移工具在同一机器上从版本 3.5 升级到版本 5.1。如果您的方案包括将一台机器上的版本 3.5 配置迁移至另一台机器上的 WebSphere Application Server - Express V5.1，则使用将版本 3.5.x 迁移至远程版本 5.1 机器中描述的备用过程。
本主题描述了使用版本 5.1 迁移工具来进行迁移：
WASPreUpgrade 工具将现有版本 3.5 配置保存到 migration-specific-backup 目录中。WASPostUpgrade 工具使用此目录来将旧的配置设置添加至新的版本 5.1 环境。
完成此任务需要执行的步骤
此 CD 上有一个 migration/bin 目录。此目录包含一个特殊环境，可以使用它来运行 WASPreUpgrade 工具而无需安装版本 5.1。
将配置保存在 migration-specific-backup 目录中：
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver
yourNodeName
验证现有环境的管理服务器正在运行。WASPreUpgrade 工具将状态显示在屏幕上，并且在 migration-specific-backup 目录的日志文件中也提供了状态。ASCII 日志文件名以文本 WASPreUpgrade 开头并且包括日期时间戳记。
WASPreUpgrade 工具将现有版本 3.5.x 配置的下列目录中的所有文件保存至备份目录：
WASPreUpgrade 工具在版本 3.5.x /bin 目录中保存所选择的文件。它还从版本 3.5.x 资源库中导出现有 Application Server 配置。WASPreUpgrade 工具调用 XMLConfig 来将现有版本 3.5 资源库导出至 migration-specific-backup 目录中的 websphere_backup.xml 文件。
如果在运行 WASPreUpgrade 工具时发生了错误，则可能必须对版本 3.5 安装应用修订才能成功完成导出步骤。有关可以应用的最新修订，请参阅“IBM 支持机构”页面。当从“信息中心”查看此信息时，单击支持以链接至“IBM 支持机构”页面。
如果出现迁移选项，不要选择它们。
在每次使用 WASPostUpgrade 之后，验证以下两个文件中的版本 5 端口设置：
如果先前版本的 BOOTSTRAP_ADDRESS 端口为 900，则迁移会将它映射至 7809。如果先前版本的 BOOTSTRAP_ADDRESS 端口不是 900，则迁移会在 Advanced Edition 迁移中将值映射至 server1，或者在 Advanced Single Server Edition 迁移中将值映射至实际的服务器名称。
WASPostUpgrade 处理将“HTTP 传输”端口从先前版本添加至版本 5 的 server.xml 文件。这意味着 server1 在共存面板和先前版本的缺省服务器中包含重复的“HTTP 传输”端口赋值。
WASPostUpgrade 工具将 WASPreUpgrade 工具创建的版本 3.5.x 配置信息迁移至版本 5.1 安装。因为版本 5.1 产品遵守 J2EE 编程模型，而版本 3.5.x 却不遵守 J2EE 编程模型，所以，需要进行重大更改来将版本 3.5.x 配置应用于版本 5.1 安装。
WASPostUpgrade 工具不会迁移样本或管理控制台应用程序，原因是版本 5.1 中已经具有样本和管理控制台应用程序。
WASPostUpgrade 工具将特定于它部署的每个企业 bean 的详细信息记录在 WASPostUpgrade.log 文件中。
在迁移之后配置 WebSphere Application Server 是一种验证迁移工具的结果的方法。也可以在迁移期间使用配置映射来验证迁移结果。本主题详细描述了迁移工具如何迁移对象以及应该验证哪些内容。
可以使用迁移工具在两台机器之间执行手工迁移。
通常，将使用 WebSphere Application Server - Express V5.1 中的 WASPreUpgrade 和 WASPostUpgrade 迁移工具在同一机器上从版本 3.5 升级到版本 5.1。
但是，在某些方案中，必须将一台机器上的版本 3.5 配置迁移到另一台机器上的版本 5.1。这些方案中的其中一个方案是为最新版本 5.1 环境安装新机器，但是需要在其它机器上迁移现有版本 3.5 配置。
本主题描述了使用版本 5.1 迁移工具来进行迁移：
WASPreUpgrade 工具将现有版本 3.5 配置保存到 migration-specific-backup 目录中。WASPostUpgrade 工具使用此目录来将旧的配置设置添加至新的版本 5.1 环境。
完成此任务需要执行的步骤
此 CD 上存在 migration/bin 目录。此目录包含一个特殊环境，可以使用它来运行 WASPreUpgrade 工具而无需安装版本 5.1。
将配置保存在版本 3.5 机器上的 migration-specific-backup 目录中。
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
adminNodeName
验证现有环境的管理服务器正在运行。
WASPreUpgrade 工具将状态显示在屏幕上，并且在 /migration-specific-backup 目录的日志文件中也提供了状态。ASCII 日志文件名以文本 WASPreUpgrade 开头并且包括日期时间戳记。
WASPreUpgrade 工具在版本 3.5.x /bin 目录中保存所选择的文件。它还从版本 3.5.x 资源库中导出现有 Application Server 配置。WASPreUpgrade 工具调用 XMLConfig 来将现有版本 3.5 资源库导出至 migration-specific-backup 目录中的 websphere_backup.xml 文件。
如果在运行 WASPreUpgrade 工具时发生了错误，则可能必须对版本 3.5 安装应用修订才能成功完成导出步骤。有关可以应用的最新修订，请参阅“IBM 支持机构”页面。当从“信息中心”查看此信息时，单击支持以链接至“IBM 支持机构”页面。
使用 FTP、共享存储器或其它某些机制来将文件复制到新机器中。
在安装了 WebSphere Application Server - Express V5.1 的机器上执行下列步骤。
现在就复制该文件，因为下一步将编辑原始文件。
对文件执行下列更改：
如果将用于原始版本 3.5 配置的节点名用于版本 5.1 机器，则不需要更改节点名。否则，必须将出现的所有版本 3.5 节点名更改为正在用于 WebSphere Application Server V5.1 的节点名。在整个文件的许多 XML 节中都出现了节点名。如果未能更改出现的所有节点名，则会导致数据的迁移不完整。
在整个文件的许多 XML 节中，配置文件都引用了路径名。即使您必须创建等价目录，也要将对版本 3.5 目录结构外部的文件的任何引用更新为新机器上的等价目录。配置相匹配的环境的含义就是可能必须将原始目录复制到版本 5.1 机器上。或者可能需要安装适当的软件。
如果路径规范与正在运行版本 5.1 的机器上的路径规范不同，则必须更正路径规范。例如，如果要从 Windows 平台上的版本 3.5 移至 Linux 平台上的版本 5.1，则必须更改配置文件中的任何特定于 Windows 的路径才能使用 Linux 路径样式。将 "c:\mystuff\somepath" 更改为 "/opt/mystuff/somepath"。
如果用户标识和密码与版本 5.1 机器上正在使用的用户标识和密码不完全相同，则必须更改用户标识和密码。
要将已编码的密码更改为纯文本密码，则应将 <password>{xor}LCoxayht</password> 更改为 <password>mypassword</password>。
配置可能引用了新机器上不存在的其它软件产品或配置。例如，旧机器可能具有数据库。V5.1 配置可能仍然指向旧机器上的数据库。修改数据源以指向版本 3.5 机器上的数据库。
使用版本 5.1 AppServer/bin 目录中的 WASPostUpgrade 工具将版本 3.5 配置添加至版本 5.1 配置。
WASPostUpgrade /opt/tmp/migration-specific-backup
WASPostUpgrade 工具将特定于它部署的每个企业 bean 的详细信息记录在 /migration-specific-backup/WASPostUpgrade.log 文件中。
可以使用版本 5.1 安装程序来从 WebSphere Application Server - Express V5.0.x 迁移至 V5.1。
完成此任务需要执行下列步骤：
使用安装根目录的 AppServer/bin 目录中的 stopServer.sh（或 stopServer.bat）脚本：
stopServer.sh server1
可以迁移版本 5.0.x 节点而无需停止它。但是，不需要使节点运行就可以迁移它的配置。迁移工具可以在节点已停止的情况下检索所有配置数据。必须停止节点之后才能启动正在安装的版本 5.1 节点。因此，现在就可以停止该节点了。
如果出现迁移选项，则选择迁移选项。
如果在安装产品结束时出现“第一步”工具，则可以使用此工具，如果由于某些原因没有出现“第一步”工具，则由您自己运行安装验证测试。
可以在方便时卸载版本 5.0.x 服务器。
可以使用迁移工具在两台机器之间进行迁移。
在开始之前
通常，将使用 WebSphere Application Server V5.1 中的 WASPreUpgrade 和 WASPostUpgrade 迁移工具在同一机器上从版本 5.0.x 升级到版本 5.1。
但是，在某些方案中，必须将一台机器上的版本 5.0.x 配置迁移到另一台机器上的版本 5.1。这些方案中的其中一个方案是为最新版本 5.1 环境安装新机器，但是需要在其它机器上迁移现有版本 5.0.x 配置。
此任务描述如何使用版本 5.1 迁移工具来执行迁移。
WASPreUpgrade 工具将现有版本 5.0.x 配置保存到 migration-specific-backup 目录中。WASPostUpgrade 工具使用此目录来将旧的配置设置添加至新的版本 5.1 环境。
完成此任务需要执行的步骤
此 CD 上存在 migration/bin 目录。此目录包含一个特殊环境，可以使用它来运行 WASPreUpgrade 工具而无需安装版本 5.1。
将配置保存在版本 5.0.x 机器上的 migration-specific-backup 目录中。
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
WASPreUpgrade 工具将状态显示在屏幕上，并且在 /migration-specific-backup 目录的日志文件中也提供了状态。ASCII 日志文件名以文本“WASPreUpgrade”开头并且包括日期时间戳记。
使用 FTP、共享存储器或其它某些机制来将文件复制到新机器中。
使用版本 5.1 AppServer/bin 目录中的 WASPostUpgrade 工具将版本 5.0.x 配置添加至版本 5.1 配置。
WASPostUpgrade /opt/tmp/migration-specific-backup
WASPostUpgrade 工具将特定于它部署的每个企业 bean 的详细信息记录在 /migration-specific-backup/WASPostUpgrade.log 文件中。
执行下列更改：
如果用户标识和密码与版本 5.0.x 机器上正在使用的用户标识和密码不完全相同，则必须更改用户标识和密码。
配置可能引用了新机器上不存在的其它软件产品或配置。例如，旧机器可能具有数据库。修改数据源以指向旧机器上的数据库。
可以迁移正在版本 5.1 不支持的操作系统上运行的 WebSphere Application Server V3.5.x 或版本 5.0.x 发行版的先前版本。
完成此任务需要执行的步骤
有两个选项。可以从版本 5.1 CD-ROM 的 platform_root 中的 migration\bin（或 migration/bin）目录中运行命令。也可以将 CD-ROM 上目录中的文件复制到在硬盘驱动器上创建的目录中。
标识版本 3.5.x 或版本 5.0.x 发行版，并标识命令存储配置文件和从以前版本迁移的应用程序的备份目录。有关命令语法，请参阅 WASPreUpgrade 主题。
标识备份目录和配置文件的位置。
CD_drive:\WASPreUpgrade backupDirectoryfilepath\WebSphere\AppServer
yourNodeName
如果这样做可行，则转至步骤 4。如果由于某些原因而不能这样做，则执行步骤 2B 到步骤 2F。
更改下列变量：
标识备份目录和配置文件的位置。
yourMigrationDirectory\WASPreUpgrade backupDirectory filepath\WebSphere\AppServer yourNodeName
如果可能的话，使系统名称和密码与旧系统的系统名称和密码相同。将与正在迁移的应用程序相关的任何数据库文件与先前系统放置在同一路径中。通常，尽量使路径保持相同。但是，不要将版本 5.1 与先前版本安装在同一目录中。如果您确实更改了路径和名称，则可以编辑 XML 配置文件以反映所作的更改。在运行下面的 WASPostUpgrade 命令之前进行这些更改。
指定 WASPreUpgrade 命令创建的备份目录（以及该目录中的任何非标准配置文件名）。有关正确的命令语法，请参阅 WASPostUpgrade 主题。
install_root\bin\WASPostUpgrade WAS_HOME\migration
本章讨论了以下迁移主题：
在 IBM WebSphere Studio Site Developer V5.1.1 中，添加了新的“确定目标服务器”功能。缺省情况下，此功能是禁用的，并且需要通过选择窗口 > 首选项 > J2EE 来在 J2EE 首选项页中启用该功能。可以在 IBM WebSphere Studio Site Developer 产品文档中找到有关“确定目标服务器”功能的运作详细信息。当启用此功能时，可以选择将特定应用程序服务器作为目标。已经实现了此功能部件以支持 JDK 1.4（它是随 IBM WebSphere Studio Site Developer V5.1.1 提供的 WebSphere Application Server V5.1 的 JRE。利用“确定目标服务器”支持的 J2EE 项目与先前版本的 IBM WebSphere Studio Site Developer 不向下兼容，因此，不能与其他人共享对 IBM WebSphere Studio Site Developer 的先前版本（例如，IBM WebSphere Studio Site Developer V5.1 和 IBM WebSphere Studio Site Developer V5.0.1）执行的操作。IBM WebSphere Studio Site Developer 提供了一种方法来在启用了此功能部件的情况下获得向下兼容性，并且在"在启用了“确定目标服务器”支持的情况下的向下兼容性"中进行了描述。造成这种不兼容性的原因在于“确定目标服务器”功能更改了 J2EE 项目上的 .classpath 文件，而先前版本的 WebSphere Application Server - Express 不能识别新的 .classpath 文件条目。
在启用了“确定目标服务器”支持的情况下，通过将目标服务器修改为在“修改目标服务器”对话框中提供不指定目标服务器选项，可以将以服务器为目标的 J2EE 项目复原为不使用“确定目标服务器”支持。“修改目标服务器”对话框是从“资源导航器”或“J2EE 透视图”视图中的 J2EE 项目上的弹出菜单（目标服务器 > 修改）中启动的。对于 EAR、EJB、应用程序客户机项目和“连接器”项目，还可以从“J2EE 属性”页（属性 > J2EE）将目标服务器修改为“不指定目标服务器”。对于 Web 项目，目标服务器设置在“Web 属性”页中（属性 > WEB）。可以在 IBM WebSphere Studio Site Developer 文档中找到有关“服务器目标”修改功能的运作详细信息。当使用了不指定目标服务器选项时，.classpath 文件就会复原到与 IBM WebSphere Studio Site Developer 的先前版本兼容的样式，并且从项目中除去了 .server。
由于 JDK 1.4 中所作的更改，当使用“数据库 Web 页面”和“Java Bean Web 页面”向导生成要在 IBM WebSphere Studio Site Developer V5.1.1 上运行的页面时，用户必须指定 Java 包。如果将“视图 Bean”模板用于“Java Bean Web 页面”向导或者“IBM 数据库存取 Java Bean 主详细信息模式”，则会产生此问题。这也适用于包含先前使用这些向导生成的在创建期间未指定包的页面和 .java 文件的项目。对于先前生成的代码，将 .java 文件移至包。然后更新 .jsp 文件，更新 import 语句和类信息。在项目的 web.xml 文件中，更新 servlet 类条目。
本章讨论了以下迁移主题：
IBM WebSphere Studio Site Developer V5.1.1 基于新的 Eclipse 基本组件 WebSphere Studio Workbench (WSWB) 2.1.2。版本 2.1.2 与 2.0.3 或 2.0.2 之间有一些差别。要获取有关这些差别的详细信息，请参阅位于 WS_Installdir\eclipse\readme 目录中的自述文件（其中 WS_Installdir 是 IBM WebSphere Studio Site Developer 的安装路径）。
IBM WebSphere Studio Site Developer V5.0 是基于 Eclipse 基本组件 WSWB 2.0.2 的，而 IBM WebSphere Studio Site Developer V5.0.1 是基于 Eclipse 基本组件 WSWB 2.0.3 的。版本 2.0.2 与 2.0.3 之间不存在任何重大差别。IBM WebSphere Studio Site Developer V5.0.1 发行版是安装在 IBM WebSphere Studio Site Developer V5.0 基础上的“更新管理器”修订包。
当第一次使用现有 IBM WebSphere Studio Site Developer V5.0 工作空间启动 IBM WebSphere Studio Site Developer V5.1.1 时，将显示一个对话框，该对话框将告诉您一种从版本 5.0 进行迁移的方法。单击确定以迁移版本 5.0 工作空间，或者单击取消以停止启动 IBM WebSphere Studio Site Developer。
迁移工作空间之后，仍然可以将该工作空间与版本 5.0 配合使用，这是因为新项目功能部件的元数据被忽略并且版本 5.0 可以读取这些元数据。在版本 5.0 中，不能对工作空间中的项目进行任何这样的更改：这些更改将影响项目的新项目功能部件的元数据或者覆盖元数据。
从版本 5 或版本 5.0.1 迁移 Java 项目是非常简单的并且可以自动完成。一旦将项目装入到版本 5.1.1 工作空间中，在 .classpath 文件或 .project 文件中就不会进行任何元数据更改（除非尝试使用版本 5.1.1 中提供的任何新功能部件）。
当开发者使用 IBM WebSphere Studio Site Developer V5 和 IBM WebSphere Studio Site Developer V5.1.1 装入和处理小组资源库中的项目时要特别小心。通常的问题是工作空间中元数据文件是否存在、其内容和解释可能特定于特定功能部件或插件版本，并且各版本会有差别。工作空间兼容性保证只包括以下情况：所有开发者在锁定步骤中都升级了他们的 IBM WebSphere Studio Site Developer 工作空间。在那些情况下，共享的元数据应不存在问题。但是，当一些开发者正在 IBM WebSphere Studio Site Developer V5.1.1 中工作而另一些开发者正在 IBM WebSphere Studio Site Developer V5 中工作时，就不具有这类保证了。本节对要执行哪些任务和不执行哪些任务提供了建议。
IBM WebSphere Studio Site Developer V5.1.1 用户会注意到典型的故障方式。当版本 5 用户保存更改，然后将更新的元数据文件提交到资源库时丢失了版本 5.1.1 的元数据。以下是可能会出错的一些事项：
以下是要在 IBM WebSphere Studio Site Developer V5.1.1 与 V5 或 V5.0.1 的用户之间共享项目时要注意的事项列表：
在 IBM WebSphere Studio Site Developer V5.1.1 中添加了此支持。有关链接的资源的信息记录在 .project 文件中。
建议：不要使用。最好是使用工作台 > 链接的资源首选项页面禁用链接的资源。
有关外部工具构建器的信息记录在 .project 文件中。版本 5 与版本 5.1.1 的信息格式有所不同。在版本 5.1.1 中创建或更改的构建器使用新的格式，版本 5 工作空间不识别该格式。在版本 5 中创建的构建器使用旧格式且在版本 5.1.1 中仍可用。
建议：总是从版本 5 工作空间创建或编辑外部工具构建器。
添加了此支持。此信息记录在 .classpath 文件中。
建议：不要指定排除模式。最好是仍然使用 Java > 编译器 > 构建路径首选项页面来禁用排除模式。
添加了此支持。此信息记录在 .classpath 文件中。
建议：不要指定除缺省（项目范围）输出文件夹之外的任何内容。最好是仍然使用 Java > 编译器 > 构建路径首选项页面来禁用多个输出位置。
当将源 ZIP 连接至 Java 构建路径上的 JAR 库时，会自动推导出源根路径前缀。自从版本 5 就已经进行了此更改，可以使用用户界面来显式设置它，并显式记录在 .classpath 文件中。因此，在 5.1.1 工作空间中创建的 Java 项目可能找不到相连接的源。
使用版本 5 来指定源附件根路径。在版本 5.1.1 中还提供了其它源连接灵活性。可以提供文件夹而不是 JAR 或 ZIP 文件作为源附件，您可以将源连接至类文件文件夹；版本 5 中未提供此功能（在版本 5 中将忽略版本 5.1.1 的信息）。
添加了使用类路径容器的 PDE。类路径容器记录在 .classpath 文件中。如果使用了 PDE 类路径容器，则版本 5 工作空间将具有未解析的类路径条目，因此，大多数 Java 功能（包括编译、搜索、运行和调试）将不会产生期望的结果。
建议：确保在创建任何新插件（或片段）项目之前禁用针对使用类路径容器的插件开发 > Java 构建路径控制首选项页面上的设置。
文件夹名是 Java Source 和 Web Content。新的 Web 项目的缺省文件夹名可通过首选项页面（窗口 > 首选项 > Web 工具 > 新项目）来配置。现在，缺省名称为 JavaSource 和 WebContent。这些缺省名将只用于新的 Web 项目。在此发行版之前的版本中创建的 Web 项目使用旧名称将继续有效。静态 Web 项目的情况相同。
如果选择更改版本 5.1.1 中的 4.0.x 和 5.0 项目的源文件夹名称，则使用“导航器”视图中的重命名弹出菜单操作。重命名弹出菜单操作将重命名文件夹名，并修正 4.0.x 和 5.0.x Web 项目的 Java 构建路径。
对于 JavaSource 文件夹，重命名弹出菜单操作在“项目导航器”视图和“包”视图中可用。对于 WebContent 文件夹，重命名弹出菜单操作在“资源导航器”视图和“项目导航器”视图中可用。
如果将此发行版之前的版本的 Web 项目保存到 SCM 资源库中，然后装入到此发行版中，则它将保留旧结构并带有 source 和 webApplication 文件夹。将正确构建这两种结构的任何一种。
Struts 工具运行时已从版本 5 中的版本 1.1 Beta 2 升级到版本 1.1。在 IBM WebSphere Studio Site Developer V5（General Availability）中，当创建 Web 项目时，可选择为项目添加 Struts 支持。可以选择 Struts 1.0.2 或 Struts 1.1 Beta 2。在 IBM WebSphere Studio Site Developer V5.1.1 中，后一种选择被 Struts 1.1 替换。如果在 IBM WebSphere Studio Site Developer V5 中创建了 Struts 1.1 Beta 2 Web 项目，则您可能想要将它转换为 Struts 1.1，但不需要进行这样的转换，因为 Struts 1.1 Beta 2 仍然受支持。如果确实具有想要转换为 Struts 1.1 的 Struts 1.1 Beta 2 Web 项目，则将需要执行下列操作：
如果您要将 IBM WebSphere Studio Site Developer V5.0.1 中的 Struts 1.1 Beta 3 Web 项目移动至 Struts 1.1，则以上所有信息都适用。
Web 服务工具添加了两种新的 IBM WebSphere Application Server V5.0.2 运行时协议，这些运行时协议只在 WebSphere Application Server V5.0.2 上运行。应该不存在强制执行的迁移，原因是 IBM WebSphere Studio Site Developer V5.1.1 和 WebSphere Application Server V5.0.2 将同时支持新旧两种运行时协议。IBM WebSphere Studio Site Developer 将生成并部署 Web 服务构件的三种运行时协议： 在 WebSphere Application Server V4.x 和 V5.x 上运行的旧“IBM SOAP”运行时协议；只在 WebSphere Application Server V5.0.2 上运行的新“IBM WebSphere 5.0.2 运行时”运行时协议；以及只在 WebSphere Application Server V5.0.2 上运行的新“Apache Axis 1.0”运行时协议。
在版本 5.1.1 中，用户不必进行更改就应该能够重用他们的版本 5 项目以及与 Web 服务相关的 EAR 文件和 WAR 文件。为了让用户将他们的 Web 服务和客户机转换为新的 IBM WebSphere 5.0.2 运行时协议并利用 JSR 101、109、WS-I 和 WS 安全标准，他们将必须通过 Web 服务向导重新生成。Web 服务资源管理器将自动继续读取用户的收藏项，但是将把物理数据文件自动移至一个新位置。
当从版本 5 迁移工作空间时，您将接收到“复原工作台时发生了问题”的弹出错误消息。如果在迁移时“概要分析”透视图打开且如果“堆”或“实例统计信息”视图在“概要分析”透视图中可见，则会出现此消息。这是因为除去了版本 5 中存在的“堆”视图和“实例统计信息”视图。如果在迁移时“概要分析”透视图在工作空间中打开，也会出现此消息。可以通过单击确定安全地忽略该错误消息。
为了使用在版本 5 中创建的定制模板，应装入定制模板，将它重新连接至数据库并保存它。下一次重新装入保存的定制模板时，将验证连接。
IBM WebSphere Studio Site Developer V4.0.3 可能不能读取在此发行版中创建的已生成 J2EE 1.2 构件，该构件可能也不能在版本 4.0.3 测试环境中运行。因为“模板”向导未随版本 4.0.3 一起交付，所以我们不会维护对该版本的向下兼容性。
如果在 Web 项目首选项中将 Java source 文件夹命名为“Java Source”并将 Web content 文件夹命名为“Web Content”，则在此发行版中生成的模板应用程序可以在版本 5 中运行。
本章讨论从 IBM WebSphere Studio Site Developer V4.0.x 迁移到 V5。
可以使用两种受支持的方法来将项目从 IBM WebSphere Studio Site Developer V4.0.x 迁移到 V5。在下面将更详细地描述这两种方法：
注意，从版本 4 迁移到版本 5 不会自动更改项目 J2EE 级别，原因是版本 5 仍可构建并部署到 WebSphere Application Server V4。所有 J2EE 项目类型（包括 Web 项目）都可以使用 IBM WebSphere Studio Site Developer 中提供的“J2EE 迁移”向导来进行迁移。要访问“J2EE 迁移”向导，右键单击 J2EE 类型项目，然后选择迁移 > J2EE 迁移向导。
以下是自版本 4.0.x 以来的增强功能的部分列表：
WebSphere 信息中心 [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/index.html] 具有下列信息：
Migrating to WebSphere V5.0 An End-to-End Migration Guide 是获取有关从版本 3.5 和版本 4.0 迁移到版本 5 的很好信息来源 [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf]。
WebSphere Application Server 下载页面 [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN－49EVRT& type=s&dt=DIAGNOSTIC+TOOL] 具有帮助转换应用程序的工具：
如果您的项目有循环依赖项，则版本 5 报告构建错误。您可以进入窗口 > 首选项 > Java > 编译器，选择构建路径选项卡，并清除检测到构建路径错误时异常终止构建复选框。注意，这将不再导致构建停止，但是“任务”视图仍将显示一个或多个构建“循环依赖项”错误（即使构建成功）。在这种情况下，可以通过选择其它选项卡而后更改循环依赖项下拉菜单中的首选项来将这些错误更改为警告。
在 IBM WebSphere Studio Site Developer V5 中，具有版本 4.0.3 中的内部项目结构更改。当版本 5 J2EE 1.2 Web WAR 与 Java 源代码一起导出时，前者将导入到 IBM WebSphere Studio Site Developer V4 中，并且源代码文件夹将自动转换为正确的名称且将正确构建。当将版本 4 项目导入版本 5 中时，Web 项目在 WebSphere Application Server V4 上同样仍能正确执行，因为源代码文件夹被自动转换成正确的名称。有关文件夹名更改的更多信息，参阅"IBM WebSphere Studio Site Developer Web 项目结构"
IBM WebSphere Studio Site Developer V5 中的内部 Web 项目结构不同于 IBM WebSphere Studio Site Developer V4.0.x 中的内部 Web 项目结构。此差别与 J2EE 1.2 和 J2EE 1.3 无关，而是工具可用性的更改。
在版本 4 中，Web 项目在缺省情况下是动态 Web 项目，并且这些 Web 项目出现在“导航器”视图中，带有 source 文件夹和 webApplication 文件夹。在版本 5 中，如果创建了动态 Web 项目，则它将带有 Java Source 文件夹（而不是 source 文件夹）和 Web Content 文件夹（而不是 webApplication 文件夹）。
但是，如果将版本 4 Web 项目保存到 SCM 资源库中，然后装入到版本 5 中，则它将保留旧的结构并带有 source 和 webApplication 文件夹。在版本 5 中将正确构建这两种结构的任何一种。
在版本 5 中，可以创建静态 Web 项目以及动态 Web 项目。
静态 Web 项目只包含静态资源（例如，HTML、Java 脚本、图像和文本等等），这些项目中不存在任何动态内容。静态 Web 项目可运行且可由传统 HTTP Web 服务器服务，而不需要 Web 应用程序服务器。
动态 Web 项目除了包含静态资源之外，还包含动态 J2EE 资源（例如，servlet、JSP、过滤器和相关联的元数据）。当您创建动态 Web 项目时，可以包括级联样式表和 JSP 标记库，以便您能够使用一组更丰富的项目资源来开始开发。动态 Web 项目始终嵌入在“企业应用程序项目”中并且只在“Web 应用程序服务器”上运行。
这是将工作空间从版本 4.0.x 移动至 IBM WebSphere Studio Site Developer V5 的建议方法。这是迁移所有信息（包括项目构建路径信息）的唯一方法。
提示：在版本 4 中，缺省情况下，工作空间目录位于安装目录中。在版本 5 中，此缺省值已经更改为 My Documents 目录中称为 workspace 的目录。如果想要覆盖存储工作的位置，则在启动工作台时，在 命令上使用 -data 选项。
对于 ClearCase：使用干净的版本 5 工作空间，然后对要装入的每个项目，选择文件 > 导入 > 将现有 WebSphere Studio 4.x ClearCase 项目导入工作空间。
迁移后注意事项：
未构建该项目，原因是它包含在循环中或有类路径问题。丢失必需的源文件夹： /MyHomePageExample403/source。
版本 4 EAR IBM 应用程序扩展文件和服务器配置文件包含绝对路径引用。在将它们迁移到版本 5 之后，需要使用它们的编辑器打开它们（这将自动将它们旧的绝对路径引用更改为新的相对路径引用）。
IBM 扩展文件包含建议不要使用的绝对路径。这可以自动更正且应该保存。这将从文件中 除去路径且只需要执行一次。想要自动更正吗？
有其它 SCM 供应商为 IBM WebSphere Studio Site Developer 提供了 SCM 插件。您可以浏览位于 www.ibm.com/software/ad/studioappdev/partners/scm.html 的供应商列表。作为他们的 Ready for IBM WebSphere Studio software [www.developer.ibm.com/websphere/ready.html] 验证的一部分，提供版本 4 插件的所有 SCM 供应商将会确保先前的迁移步骤（从版本 4 保存到 SCM 资源库，从资源库装入到版本 5）也适用于他们的系统。
这种方法部分受支持，并且将产生不完整的迁移。用户界面设置、调试设置和大多数首选项全部丢失。保留项目名称、项目源文件和项目 Java 构建路径（类路径），但不作任何其它保证。仅当未使用任何受支持的 SCM 系统，且保留项目构建路径信息（这些信息在导入从版本 4 导出的项目时丢失）很关键时，才应该使用此方法。可以通过执行以下步骤来使用现有的版本 4.0.x 工作空间：
迁移后除去 EAR 和“服务器配置”绝对路径引用中描述的迁移后指示信息也适用于此处。
如果尝试通过在 IBM WebSphere Studio Site Developer V5 中打开版本 4.0 工作空间来进行迁移，则可能产生以下问题。
要将 JRE_LIB 类路径变量重新设置为有效位置，遵循以下步骤。当您第一次打开“首选项”窗口时，即使值看起来是正确的，也要执行此操作。
如果不这样做，则 JRE_LIB 的值可能不正确，会在 Java 文件中导致许多构建错误。
作为全面检查，验证所有其它类路径变量的值是否正确。
在 Eclipse 1.0 与 2.0 之间，“小组”支持已显著更改。也更改了共享资源库项目的方法。
缺省情况下，将在工作空间目录中创建项目。如果覆盖缺省值以在别处创建项目，则在关闭工作台之前必须打开所有项目。这允许将项目的 .project 文件写入正确的位置。不能打开其目录在工作空间外的已关闭项目，这将产生这样一个项目：它掩盖实际的项目，并且其中只有一个 .project 文件。
您将需要除去现有的任何 JSP 断点，并在迁移的版本 5 工作空间中重新设置它们。
要从 IBM WebSphere Studio Site Developer 4.0.3 项目迁移关系数据：
将复原关系数据构件。
如果已经从 4.0.x 导入了 Web 服务文件，则可能会接收到下列错误消息：
错误 “结果”部分为它的类型定义了无效值“anyElement”。
类型声明必须引用模式中定义的有效值。 错误 “返回”部分为它的元素定义了无效值“findPatientResult”。
元素声明必须引用在模式中定义的有效值。 错误 “响应”部分为它的元素定义了无效值“findPatientResponse”。
元素声明必须引用在模式中定义的有效值。
变通方法是：
要访问版本 5 中的“J2EE 迁移”向导，遵循下面的步骤：
本章说明如何从 WebSphere Studio V4.0（Advanced Edition 和 Professional Edition）迁移到 IBM WebSphere Studio Site Developer。从 WebSphere Studio "Classic" V4.0 迁移到 IBM WebSphere Studio Site Developer V5.0 涉及到下列步骤：
IBM WebSphere Studio Site Developer 中未提供 WebSphere Studio "Classic" 的高级发布功能部件（将文件映射至发布阶段）和 Page Detailer 功能部件（Web 页面的分析）。版本 4.0.x CD 媒体包中的一些其它功能部件也不再可用。例如，用于分析 Web 页面的 Page Detailer 功能部件、用于各种媒体类型的 HotMedia(R) 功能部件、语音 XML 编辑器（移动至 WebSphere Everyplace(TM) Toolkit 和 Portal Toolkit）和用于普及型设备的 DataBaseWizard。
在迁移任何 WebSphere Studio 数据之前应该注意以下限制：
在以下概括的迁移过程中，WebSphere Studio 为单服务器创建了包含所有项目文件（可发布的和源代码）的 JAR 文件。在缺省服务器的“发布”视图中可见的所有文件将被打包到该 JAR 文件中。然后可以将 JAR 文件导入 IBM WebSphere Studio Site Developer。
当迁移现有项目时，所有的项目发布信息和阶段信息都将在迁移过程中丢失。如果您所处的阶段中有多个服务器，则将只保留发布到缺省服务器的文件。因此，为了迁移的目的，将创建仅有一个服务器的新阶段。
如果在当前阶段中有多个服务器，则通过以下步骤创建仅有一个服务器的称为“迁移”的阶段：
缺省 Web 配置描述符文件名是 serverName_web.xml，在本方案中的名称是 localhost_web.xml。除非指定了不同的位置，否则 .xml 文件保存在 WEB-INF 目录中。
现在应用程序测试已就绪。要在缺省测试服务器上测试它，遵循这些步骤：
要在其它服务器运行时环境中测试应用程序，参阅“服务器工具”功能部件联机帮助。
本章说明如何从 VisualAge(R) for Java Professional Edition 或 VisualAge for Java Enterprise Edition 迁移到 IBM WebSphere Studio Site Developer。
Instantiations, Inc.（IBM 的一个业务合作伙伴）分发称为 CodePro Studio 的产品，该产品向 VisualAge for Java 和 WebSphere Application Server - Express 提供了一些效率上的增强功能，包括迁移和共存工具。为了帮助 VisualAge for Java 客户开始进行迁移，Instantiations 为 IBM WebSphere Studio Site Developer 导出设置提供了免费的无限制使用的 VisualAge for Java，作为他们的
CodePro Studio 的限时评估副本的一部分。可以从 www.instantiations.com/vaj-migrate 下载评估副本。有关
Instantiation 的高级迁移和共存支持（包括文件的完全双向导出／导入、创建导出／导入集、项目同步和任务自动化）的进一步信息，请浏览
Instantiations, Inc. 的站点 www.instantiations.com/codepro/ws。
以下是从 VisualAge for Java 进行的更改的部分列表：
以下步骤概括了如何从 VisualAge for Java 进行迁移。下面提供了有关如何执行这些步骤的详细信息：
不支持从 VisualAge for Java 资源库大量迁移已设置版本的项目和资源。只能迁移 VisualAge for Java 工作空间中的项目和资源。如果想要将项目或资源的已设置版本的副本迁移到 IBM WebSphere Studio Site Developer，则必须将它放入 VisualAge for Java 工作空间中，然后迁移它。
遵循以下步骤来将项目导出到 JAR 文件中：
启动 IBM WebSphere Studio Site Developer，然后创建适当的项目。以下是一组一般迁移指导，帮助您决定应将文件导入何种类型的 IBM WebSphere Studio Site Developer 项目：
如果应用程序使用 servlet，则需要在 web.xml 文件中定义 servlet-URL 映射。遵循以下步骤：
必须记录以下 VisualAge for Java 设置并在 IBM WebSphere Studio Site Developer 中设置它们：
项目类路径
在 VisualAge for Java 中，在“选项”窗口的“资源”页面中设置项目类路径（窗口 > 选项 > 资源）。在将项目迁移到 IBM WebSphere Studio Site Developer 中之后，可以在项目的“属性”窗口中设置项目的类路径（右键单击项目，然后选择属性 > Java 构建路径。单击库选项卡。）也可以在“首选项”窗口中设置类路径变量（窗口 > 首选项 > Java > 类路径变量。）
资源关联
如果在文件类型和可执行文件之间设置关联，可以从工作台中打开工作台之外的文件。
在 VisualAge for Java 中，在“选项”窗口中设置资源关联（窗口 > 选项 > 资源 > 资源关联）。在已将资源文件迁移到 IBM WebSphere Studio Site Developer 之后，可以使用“首选项”窗口来设置资源关联（窗口 > 首选项 > 工作台 > 文件关联）。
代码格式化程序
在 VisualAge for Java 中，在“选项”窗口的“格式化程序”页面中设置代码格式化选项（窗口 > 选项 > 编码 > 格式化程序）。在将代码迁移到 IBM WebSphere Studio Site Developer 之后，可以在“首选项”窗口中设置代码格式化（窗口 > 首选项 > Java > 代码格式化程序）。
WTE 配置
在 VisualAge for Java 中，“WebSphere 单元测试环境”和 WebSphere Application Server 运行时设置位于以下目录中的不同属性文件内：VisualAgeInstalldir\ide\project_resources\IBM WebSphere Test Environment\properties，其中，VisualAgeInstalldir 是产品安装目录。
例如，如下所示已通过在 session.xml 属性文件中将属性更改为 true 来启用了 URL 重写 <url-rewriting-enabled>true</url-rewriting-enabled>，则可以在 IBM WebSphere Studio Site Developer V4.0 测试环境中配置此属性。（在“服务器”透视图中，打开“服务器配置”视图，右键单击想要使用的服务器，并单击打开。单击 Web 选项卡，然后选择启用 URL 重写复选框）。
Java 文件和项目资源文件
属性文件 default.servlet_engine 包含 VisualAge for Java Web 应用程序的上下文根 <root-uri>。当在 IBM WebSphere Studio Site Developer 中创建“Web 项目”时，创建 Web 项目对话框包含用于该数据的上下文根字段。
应该将自己定制的文件（例如，VisualAgeInstalldir\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp）中的 Web 应用程序设置迁移到 IBM WebSphere Studio Site Developer 中的 your_Web_project\Web Content\WEB-INF\web.xml 文件。例如，如果已经在 default_app.webapp 文件中更改了 servlet 名称和 servlet 路径，则将在 web.xml 文件中作相应的更改。
如果应用程序是 Java 项目，则只使用 Java 项目的正常 IBM WebSphere Studio Site Developer 运行或调试支持来测试它。
如果应用程序使用 WebSphere Application Server，则使用内置 WebSphere Application Server 测试它。这要求创建和启动缺省测试服务器。对于 Web 项目，右键单击 HTML 主页，然后选择在服务器上运行来启动 Web 浏览器。
有关测试其它类型项目的信息，请参阅联机帮助。
如果正在使用 WebSphere Application Server 作为运行时环境，则使用 IBM WebSphere Studio Site Developer 的“服务器工具”功能部件来部署应用程序。
IBM WebSphere Studio Site Developer 项目（及其相关联设置）可以在各开发者间共享。为此，将项目保存到 IBM WebSphere Studio Site Developer 软件配置管理（SCM）服务器，然后将它解压缩到 IBM WebSphere Studio Site Developer 的另一个小组成员上。
有关 IBM WebSphere Studio Site Developer V4.0 中小组支持的信息，参阅 www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.html
在《安装指南》和联机帮助中也提供了有关 IBM WebSphere Studio Site Developer 中的小组支持的信息。
本章提供有关如何将在 VisualAge for Java 的“可视化组合编辑器”功能部件中创建的应用程序迁移到 WebSphere Application Server - Express 中的 Visual Editor for Java 的指示信息：
此步骤是可选的，但是由于下列原因，强烈建议您执行此步骤（尤其是在应用程序具有任何连接的情况下）。
要在迁移之前保存增强的元数据信息：
现在，就可以将类导入 WebSphere Application Server - Express 了。参阅第 7 章 "从 VisualAge for Java 迁移到 IBM WebSphere Studio Site Developer"中先前的信息。一旦将先前的“可视化组合编辑器”源程序导入 WebSphere Application Server - Express，就可以将它们保留在 Visual Editor for Java 中。
本章讨论了以下迁移主题：
有关所包含信息的详细说明，请参阅有关阐明 J2EE 类装入的相关文档（www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html） （J2EE 模块和类路径）以及有关开发 J2EE 实用程序 JAR 的相关文档（www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html）（J2EE 模块中的 Java JAR）。它们会提供极好的技术背景和相当不错的建议。
在 Web 项目中使用第三方 JAR 文件的建议方法是将它（作为 JAR 文件保存）导入 Web 项目的库文件夹。这是唯一由 J2EE 定义的且可移植的使用 JAR 文件的方法，而且将确保在部署到另一个服务器时不必做任何更改。
要在单个 Web 项目中使用外部 JAR 文件，遵循以下步骤。如果需要在多个 Web 项目中使用该 JAR 文件，则遵循"使用第三方 JAR 以与多个 Web 项目配合使用的建议方法"中描述的步骤。
将第三方 JAR 文件与两个或多个 Web 项目配合使用的建议方法是将它（保持为 JAR 文件）导入“企业应用程序”（EAR）项目中。这是唯一由 J2EE 定义的且可移植的使用 JAR 文件的方法，而且将确保在部署到另一个服务器时不必做任何更改。
要将外部 JAR 文件与多个 Web 项目配合使用，遵循下列步骤。如果只需要在单个 Web 项目中使用 JAR 文件，则遵循前面一节中的步骤。
也可以将 JAR 文件留在 WebSphere Application Server - Express 外面并且将它添加到 Java 构建路径和服务器实例的类路径中。建议不要这样做，因为应用程序将不容易移植。当移到不同的服务器时，始终要更新服务器的类路径。另外，您需要确保类文件与服务器类路径上已存在的（且为服务器或它的其它应用程序所必需）相似类文件的其它版本不冲突。如果确定使用这个方法，执行以下步骤：
WebSphere Application Server - Express 的功能强大的自动构建功能在复杂多项目构建期间可以降低构建性能。有一些方法能控制这些自动构建（从属文件、活动和不活动的项目以及源代码或 JAR 格式的项目），但是这些选项可能会很复杂。有一篇文章解释了这些选项以及如何优化构建性能。请参阅 WebSphere 开发者园地文章 Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer（www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html）。
可以将 Ant 与 WebSphere Application Server - Express 配合使用来使生产构建自动化。有一个多部分文档说明了以下内容：
请参阅 WebSphere 开发者园地文章 Using Ant with WebSphere Studio Application Developer（www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html）。
本章包含迁移示例，以帮助您了解有关从 VisualAge for Java 和 WebSphere Studio "Classic" 迁移到 WebSphere Application Server - ExpressIBM WebSphere Studio Site Developer 的更多知识。
描述
这是 VisualAge for Java V4.0 提供的 FindTheLeapYears 样本。有关它的信息可以在 VisualAge for Java 联机帮助中找到（样本 > JSP/Servlet 开发环境）。
迁移概述
将遵循以下步骤从 VisualAge for Java 将样本迁移到 IBM WebSphere Studio Site Developer。下面更详细地讨论了这些步骤：
通过以下这些步骤将 Java 源文件导入 LeapYear 项目源目录：
遵循下列步骤将资源文件导入 WebContent 目录下的 LeapYear 项目：
由于稍微更改了源代码／应用程序结构，现在需要进行一些应用程序更改：
此时，已经将样本迁移到 IBM WebSphere Studio Site Developer 中。剩下来的所有工作就是创建 IBM WebSphere Studio Site Developer 服务器项目并且在 WebSphere 测试环境中测试样本。
现在，需要将 EAR 项目指定到服务器配置中：
描述
对于此示例，必须使用 WebSphere Studio Classic V4.0.x。
将要使用的样本是 YourCo 样本。要访问此样本，打开联机帮助（帮助 > WebSphere Studio 4.0 > 如何 > 使用样本 > 概述）。要装入此样本，遵循打开 Studio 样本（对于 WebSphere Application Server 4.0）中的指示信息并装入 YourCo.war。
在开始之前
迁移步骤
要将此样本从 WebSphere Studio "Classic" 迁移到 IBM WebSphere Studio Site Developer，将遵循以下步骤。在下面更详细地描述了每一步骤。
（可选）通常，要创建新的迁移阶段，但是对于此示例，使用 WebSphere Studio Classic 附带的“测试”阶段。使用“测试”阶段将不必在步骤 8 中手工编辑许多 servlet 映射。
有关如何创建新的迁移阶段的信息，参阅“从 WebSphere Studio "Classic" 迁移到 IBM WebSphere Studio Site Developer”。
a. com.ibm.db 需要 databeans.jar， b. com.ibm.webtools.runtime 需要 webtlsrn.jar， c. com.ibm.ejs.ns.jndi 需要 ns.jar， d. com.ibm.webshpere.advanced.cm.factory 需要 cm.jar， e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions 需要 ws-base-extensions.jar
要修正此情况，必须修改 Web 项目的 Java 构建路径。
此时，已经将样本迁移到 IBM WebSphere Studio Site Developer 中。剩下来的所有工作就是创建 IBM WebSphere Studio Site Developer 服务器项目并且在 WebSphere 测试环境中测试样本。
现在，需要将 EAR 项目指定到服务器配置中：
以下网址提供有关迁移和其它主题的最新信息：www.ibm.com/websphere/developer/zones/studio/transition.html
以下出版物和 Web 页面提供了在使用 WebSphere Application Server - Express 时可能会有帮助的一般信息：
您可能感兴趣的其它阅读材料：
Note to U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
本信息是为在美国提供的产品和服务编写的。IBM 可能在其它国家或地区不提供本文档中讨论的产品、服务或功能特性。有关您当前所在区域的产品和服务的信息，请向您当地的 IBM 代表咨询。任何对 IBM 产品、程序或服务的引用并非意在明示或暗示只能使用 IBM 的产品、程序或服务。只要不侵犯 IBM 的知识产权，任何同等功能的产品、程序或服务，都可以代替 IBM 产品、程序或服务。但是，评估和验证任何非 IBM 产品、程序或服务，则由用户自行负责。
IBM 公司可能已拥有或正在申请与本文档内容有关的各项专利。提供本文档并未授予用户使用这些专利的任何许可证。您可以用书面方式将许可证查询寄往：
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
有关双字节（DBCS）信息的许可证查询，请与您所在国家或地区的 IBM 知识产权部门联系，或用书面方式将查询寄往：
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
IBM 可以按它认为适当的任何方式使用或分发您所提供的任何信息而无须对您承担任何责任。
本条款不适用英国或任何这样的条款与当地法律不一致的国家或地区：国际商业机器公司以“按现状”的基础提供本出版物，不附有任何形式的（无论是明示的，还是默示的）保证，包括（但不限于）对非侵权性、适销性和适用于某特定用途的默示保证。某些国家或地区在某些交易中不允许免除明示或默示的保证，因此本条款可能不适用于您。
本信息中可能包含技术方面不够准确的地方或印刷错误。此处的信息将定期更改；这些更改将编入本资料的新版本中。IBM 可以随时对本资料中描述的产品和／或程序进行改进和／或更改，而不另行通知。
本程序的被许可方如果要了解有关程序的信息以达到如下目的：（i）允许在独立创建的程序和其它程序（包括本程序）之间进行信息交换，以及（ii）允许对已经交换的信息进行相互使用，请与下列地址联系：
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canada L6G 1C7
只要遵守适当的条件和条款，包括某些情形下的一定数量的付费，都可获得这方面的信息。
本资料中描述的许可程序及其所有可用的许可资料均由 IBM 依据 IBM 客户协议、IBM 国际程序许可证协议或任何同等协议中的条款提供。
涉及非 IBM 产品的信息可从这些产品的供应商、其出版说明或其它可公开获得的资料中获取。IBM 没有对这些产品进行测试，也无法确认其性能的精确性、兼容性或任何其它关于非 IBM 产品的声明。有关非 IBM 产品性能的问题应当向这些产品的供应商提出。
本信息中对非 IBM Web 站点的任何引用都只是为了方便起见才提供的，不以任何方式充当对那些 Web 站点的保证。那些 Web 站点中的资料不是 IBM 产品资料的一部分，使用那些 Web 站点带来的风险将由您自行承担。
本信息包含在日常业务经营中使用的数据和报告的示例。为了尽可能完整地说明这些问题，示例中可能会包括个人、公司、品牌和产品的名称。所有这些名称都是虚构的，如与实际商业企业所使用的名称和地址有任何雷同，纯属巧合。
版权许可：
本信息包括源语言形式的样本应用程序，这些样本说明不同操作平台上的编程方法。如果是为按照在编写样本程序的操作平台上的应用程序 编程接口（API）进行应用程序的开发、使用、经销或分发为目的，您可以任何形式 对这些样本程序进行复制、修改、分发，而无须向 IBM 付费。这些示例并未在所有条件下作全面测试。因此，IBM 不能担保或暗示这些程序的可靠性、可维护性或功能。用户如果是为了按照 IBM 应用程序编程接口开发、使用、经销或分发应用程序，则可以任何形式复制、修改和分发这些样本程序，而无须向 IBM 付费。
凡这些样本程序的每份拷贝或其任何部分或任何衍生产品，都必须包括如下版权声明：
(C)（贵公司的名称）（年）。此部分代码是根据 IBM 公司的样本程序衍生出来的。
(C) Copyright IBM Corp. 2000, 2003. All rights reserved.
编程接口信息用来帮助您使用此程序来创建应用软件。
通用编程接口允许您编写获取此程序工具的服务的应用软件。
然而，本信息还可能包含诊断、修改和调整信息。诊断、修改和调整信息用来帮助您调试应用软件。
警告：不要将此诊断、修改和调整信息用作编程接口，因为它是会更改的。
下列各项是国际商业机器公司在美国和／或其它国家或地区的商标或注册商标：
Java 和所有基于 Java 的商标和徽标是 Sun Microsystems, Inc. 在美国和其它国家或地区的商标或注册商标。
ActiveX、Microsoft、Windows、Windows NT 和 Windows 徽标是 Microsoft Corporation 在美国和／或其它国家或地区的商标或注册商标。
UNIX 是 The Open Group 的注册商标。
其它公司、产品和服务名称（可能用双星号（**）表示）可能是其它公司的商标或服务标记。
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.