调试在 WebSphere Application Sever 内运行的 Java 代码

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Joe Winchester (joewin@us.ibm.com), WebSphere 工具开发者, IBM Raleigh 实验室

2001 年 11 月 01 日

这篇文章讲述了怎样调试在 WebSphere Application Server 内运行的 Java 代码，比如 servlet、EJB 或 JSP。

©2001 International Business Machines Corporation. All rights reserved.

介绍

IBM Distributed Debugger 使您能够调试 Java™ 代码，设置断点，在捕获到异常时停止，以及逐条语句单步调试程序。该系列以前的文章描述了怎样获得和安装这种 Debugger，以及怎样用它来调试应用程序。这篇文章集中于您想要调试在 WebSphere®Application Server 内运行的 Java 代码（如：servlet、EJB 或 JSP™）的情况。该篇文章的侧重于 IBM Distributed Debugger 9.1 和 WebSphere Application Server 4.0，两者都有高级版（AE）和高级单服务器版（AEs）。

您可以以两种方式调试在 WebSphere Application Server 中运行的 Java 程序：

• 配置 WebSphere Application Server 来启动它的 JVM，它作为 Debugger 可以定位和连接的调试对象。
• 使用 Object Level Trace（OLT）实用程序。

回页首

启动 WebSphere Application Server AEs 作为调试对象

为了以调试方式启动 WebSphere Application Server AEs，修改 startServer 程序参数。参数 -debugEnable 用来以 JPDA 调试方式启动（使用套接字连接器）JVM，参数 -jdwpPort 用来指定端口号。这在下面的图 1 中展示出来了，它告诉 WebSphere Application Server 启动 JVM，它作为在端口 3001 侦听 Debugger 连接的调试对象。要获取更多的关于 JPDA 和套接字连接器的信息，请参阅我以前的文章 远程调试：使用 IBM Distributed Debugger 和 JDB。

当 startserver 运行，它缺省地使用 server-cfg.xml 配置文件，该文件包含关于要被启动的服务器的详细信息。您可以修改关于调试的信息，比如是否启用调试，通过直接修改配置文件而不是每一次运行 startserver 时指定 -debugEnable 参数。要明白怎样使用管理控制台（Administrative Console）完成这些，请参阅 OLT 工具章节。

回页首

以调试方式启动 AE

对于 AE，为了进行调试，您必须使用管理控制台来配置服务器。在启动管理控制台之前，必须启动管理服务器（Administrative Server）。AE 安装和配置比 AEs 复杂得多，并且存在一些可能阻止管理服务器正确启动的问题。为了查找启动管理服务器的故障问题，请参照 WebSphere 信息中心的问题确定章节。

一旦您启动了管理服务器，可以通过选择 Start => Administrator's Console，或在 First Steps 对话框通过选择 Start the Administrative Console启动管理控制台。如下面的图 2 所示，在该控制台展开您想要调试的服务器。

在您希望配置用作调试的服务器上，选中 JVM Settings标签并且选中 Advanced JVM Settings。这将会打开如下面的图 3 所示的对话框。

当您选中 Enable debug mode，它将参数 -Xdebug 和 -Xnoagent 添加到由 WebSphere Application Server 使用的 Java 命令的命令行。为了指定更多的参数，比如 Debugger 用来连接调试对象的端口号，输入 -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=nnnn 其中 nnnn 是套接字号。在关闭了这个对话框之后，上面的图 2 展现，您可以看到命令行参数的全部设置。在修改了 JVM 参数之后，您必需停止服务器并且再次启动它，使参数生效。您可以通过在服务器的弹出菜单上选择 Stop来停止，通过选择 Start来重新启动它。不要选择 EnableIBM distributed Debugger? 这只用于 Degugger 和 OLT 工具一起使用时。

回页首

将 Distributed Debugger 连接到 WebSphere Application Server

前面的章节说明了怎样配置 WebSphere Application Server AE 和 AEs，使其用套接字连接器以调试方式启动它的 JVM，允许调试器在端口 3001 进行连接。现在我们将向您展示怎样用 Distributed Debugger 连接 WebSphere Application Server JVM 以及调试 servlet、EJB 和 JSP。为了完成这些，我们将使用 AE 和 AEs 的示例包都提供的 HitCount 示例。

为了启动 Distributed Debugger，打开命令提示符，转到 Debugger 所在的目录 ? 通常是 C:\IBMDebug\bin 。确保位于 JDK bin 目录的 java.exe 是最先出现在 path 中的 java.exe ；否则，Distributed Debugger 将不能定位调试所要求的必需的 JDK 类。如下面的图 4 所示，您可以通过改变系统路径或会话路径来完成这些。

在您启动 Distributed Debugger 的机器上进行您的测试。在上面的图 4 中，与 WebSphere 一起使用 JDK，即使如果您是在没有安装 WebSphere ApplicationServer 的机器上用 Debugger 进行远程调试，要确保 WebSphere Application Server 的 JDK 级别和使用 Debugger 用户界面的机器是相同的。命令 java -version 将向您展示 JDK 的级别。

如上面图 4 所示使用 -a 选项，可以启动 Debugger 的同时，设置调试器自动为准备连接状态。这将打开如下面的图 5 所示的连接对话框。如果 Distributed Debugger 没有在 Interpreted 记事本页面打开，这是因为以前您没有用它调试 Java 程序。在 DbgProf 目录您的概要文件中，Debugger 记录了您最近一次调试会话的详细信息，如果没有这样的历史记录，连接对话框将打开 Compiled 页面。为了使得 Interpreted 页面打开，使用选项 idebug -qlang=Java-a 。在连接对话框中，输入正在运行 WebSphere Application Server 的机器的名称（本例为 JoeWin.raleigh.ibm.com）以及用作 jdwp 套接字协议参数的端口号（即 3001）。您可以使用数字的 IP 地址，代替使用机器名。要获取关于使用 Distributed Debugger 进行远程调试的更多信息，请参阅本系列中 以前的文章。

在如上面的图 5 所示的对话框中单击 Attach之后，Distributed Debugger 设法在机器上定位调试对象，该机器的名称是在 JVM host 字段指定的，它一直在3001端口监听 JDWP 套接字连接。当 Debugger 正在定位和连接 JVM 时，将显示一个进度对话框，并且当 Debugger 被正确连接时，将显示 WebSphere Application Server JVM 的堆栈框架。耐心一些，Debugger 进行连接可能要花费 30 秒左右的时间。

一旦 Debugger 定位并连接了 WebSphere Application Server JVM，它将使 JVM挂起，并试图向您显示被停止位置的堆栈框架以及源代码。通常这是 java.lang.Object 中的 wait() 方法，并且试图显示源代码，您将被提示为 java.lang.Object 输入源代码的位置。大多数情况下，您可以取消这个对话框，然后定位您想要调试的类。对于 Debugger，如果您真的想要使用 JDK 源文件，这些不作为 WebSphere 的一部分提供，您必须从 JDK 供应商处获取。一旦您获得了这种源文件，您将需要解压缩文件 src.jar ，并且在 Debugger 的 Source Search path 将位置指定为 /src 目录。关于这些更多的信息可以在 以前的文章中找到。在 Debuggger 连接到 WebSphere Application Server JVM 之后，它将暂时挂起 JVM，这时单击Run就可以使 WebSphere Application Server 继续工作。

我们将要调试的 HitCount 应用程序包含在 sampleapp.war 文件的 sampleApp.ear 中，它由调用 servlet 的 JSP 组成。要运行这个示例，将您的浏览器指向 http://HOSTNAME/webapp/examples/HitCount，其中 HOSTNAME 是正在运行 WebSphere Application Server 机器的名称或 IP 地址。对于这篇文章，WebSphere Application Server 与 Debugger 在同一机器上，因此这里是 localhost。在 HitCount 示例中，根据初始页面上所选的单选按钮值，用 servlet 或 EJB 进行不同的调用来增加点击计数器次数。请参阅下面的图 6。

首先，我们将给 HitCount servlet 类添加一个断点。使用装入的包的列表来查找这个类。如下面的图 7 所示， HitCount.java 文件没有在它的源代码中指定包，因此它是缺省包的一部分。

在选择了 HitCount 类之后，Debugger 试图装入源文件。不是在 Source Not Found 对话框给单独的 Java 文件指定源文件，而是取消该对话框，通过选择 Source => SourceSearch Path改变 Debugger 用来定位源文件的路径。下面的图 8 显示了在 SourceSearch Path 中输入的包含 HitCount.java 文件目录的位置。除了在 Debugger 源文件搜索路径指定源文件的路径外，在 AEs 中，对于 startServer 命令，您可以使用 -debugSource 参数。在系统范围内，您可以改变源文件路径，缺省的情况下，Debugger 使用 DER_DBG_PATH 环境变量。AE 和 AEs 的管理控制台使您能够指定调试源文件路径，但是这只是当使用 OLT 时有效。

单击 HitCount source not found 对话框上的 Cancel之后，接着修改 Source Search Path，您将需要让 Debugger 自己刷新来显示源文件。您可以通过选择 Source=> Change Text File => OK来完成这些。接着 Debugger 将试着从当前源文件搜索路径装入 HitCount.java ，并且进行修改，应该如前面图 7 所示源代码出现，显示在第 94 行，即 servlet 的 service(HttpServletRequest,HttpServletResponds) 方法的第一条可执行语句添加了断点。单击 Run，让 WebSphere Application Server 继续运行，这时 Debugger 将再次被挂起。

单击 Increment之后，将调用 servlet 并且到达断点。Debugger 将被启用，并且突出显示第 94 行。从这里，您可以单步调试源代码，检查变量，设置要捕获的异常以及添加新的断点来帮助您理解程序执行。单击 Run将使 servlet 继续执行，Debugger 将再次挂起。当 WebSphere ApplicationServer 正在运行时，在任何一点，您可以通过单击 Halt使它停止，这将暂挂 WebSphere Application Server JVM，使您可以再次调试它。当 WebSphere Application Server JVM 被暂挂，Web 浏览器可能超时，因为在设置时间和假定 Web 站点不可用之后，它不能从服务器得到响应。关于怎样改变不同浏览器超时设置的详细信息，请参阅 WebSphere Application Server InfoCenter。

为了在 HitCount servlet 中插入断点，我们必须在所装入的包的列表中找到该程序，本例在<default> package 中。如果 WebSphere Application Server JVM 还没有装入您想要调试的类，它将不会在列表中显示。要给还没有装入的程序添加断点，在 Breakpoints 菜单使用 Set Line或 Set Method选项。如下面的图 9 所示，在这些对话框中选择 Deferred Breakpoint，当该类最先由正在被调试的 JVM 装入时，将添加断点。

当您添加了行断点，源文件通常是可选的。但是，如上面的图 9 所示，一旦您选择了 Defer 断点，您必须输入源文件。HitCount 类在缺省的包中，因此输入它的源文件为 HitCount.java 。但是，如果类在某个包中，那么输入恰当的源文件，比如：如果 HitCount 在包 com.ibm.examples 中，输入 com\ibm\examples\HitCount.java 。如果您不输入源文件，您不会得到一个错误，但是将不能添加断点。如果您不知道源代码的行，但是运行到方法时希望 Debugger 停止，那么您可以创建一个 Defer 的方法断点。您所需要做的是输入包名、类名以及方法签名。这里 Distributed Debugger 非常聪明，因为您不需要完全描述要使用的方法签名。例如，该服务方法完整的方法签名是

service(javax.servlet.http.HttpServletRequest,
  javax.servlet.http.HttpServletResponse)
    

但是，如果您仅仅是不带参数输入 service 作为方法名，那么您将得到与该名称相匹配的所有方法的方法断点。这非常有用，因为它意味着您不必要完全描述难以记住的方法名。

HitCount 示例包括不同数目的 Java 类类型、servlet、EJB 以及 JSP。可以象调试 servlet 那样调试 EJB。例如，如果在 HitCount 页面，您选择单选按钮来使用 EJB，EJB com.ibm.WebSphere.examples.Inc.IncBean 将被用来检索值。您可以在包列表浏览这个类，展开它的方法，并且在 getValue() 方法中添加断点。对于 IncBean，WebSphere 不提供源代码，但是即使没有源代码您仍然能够添加方法断点。对于复杂的多层的情况（不同的 WebSphere Application Server 上，servlet 和 JSP 的 EJB 不同 ），您将需要使用 OLT 来完成跨越不同服务器的同步调试。通过一个套接字将 Distributed Debugger 连接到 JPDA 调试对象只能被用来调试单 JVM。

调试 JSP 有一点不同，因为当 JSP 页面在运行时作为 servlet 执行，对于 servlet，它们的源代码是 Java 文件。JSP 源文件是 HTML 和 Java 的混合物，由 WebSphere Application Server 页面编译器组合，创建 servlet 源文件。上面的图 7 展示了在所装入的类中，HitCount.JSP 以 HitCount_jsp_0 存在 ? HitCount.jsp 被预编译成的 servlet 名称。JSP 预编译所存在的问题是，作为一个开发者，您不是真正对调试 servlet 感兴趣，而是当编写了 JSP 源代码时，您想要调试它。JPDA 有称为 Java 虚拟机调试界面（JVMDI）的一层，能够使执行环境如：WebSphere Application Server 内部使用 Java 类的一种表示法，而外部 Debugger 用户界面使用初始的源代码。

要看到这些，在上面的图 7 中的所装入类的列表中选择文件 HitCount_jsp_0 。不是提示输入 servlet 源文件的位置，即 HitCount_jsp_0.java ，Debugger 将提示输入 JSP 文件的位置。请参阅下面的图 10。

正出现的是 Debugger 用户界面正向 WebSphere Application Server JVMDI 请求源文件 HitCount_jsp_0 ，WebSphere Application Server 知道这是一个由 JSP 页面创建的 servlet，因此它向 JSP 源文件页面返回源文件的名称。Distributed Debugger 在其源文件搜索路径中没有文件 HitCount.jsp ，因此将提示您输入它。在您输入 HitCount.jsp 文件的位置后，它将被打开。

在上面的图 11 中，展开了 HitCount_jsp_0 方法的列表，并且在 _jspService(HttpServletRequest,HttpServletResponds) 添加了断点。在源代码窗格 JSP 的第 1 行，开始的 <HTML> 标记符处显示了红色的断点标记。当装入 JSP，Debugger 将在这一行停止，您可以通过 JSP 源代码继续调试预编译的 servlet。Step Over 功能使您一行一行单步调试语句。当您输入一个 scriptlet，如在第 11 行，您可以使用 Step into 功能进入 Java scriptlet 方法调用，比如 response.setHeader(String,String) 方法。

此外，对于 JSP 使用 Step 功能，您可以通过在页边空白处双击添加行断点。向 WebSphere Application Server JVMDI 请求在给定行号处添加断点，WebSphere Application Server 将该 JSP 语句号映射成为正确的 servlet 语句号，并且添加断点。如果对于断点这个位置无效，将显示错误对话框。

在 WebSphere Application Server 4.0 中，对 JSP 调试作了一些修改和修正。与 AE 的 GA 级或 AEs 的 PTF 级一起使用 Debugger 的 9.1.5 版本。

回页首

用 Object Level Trace（OLT）进行调试

调试在 WebSphere ApplicationServer 内运行的代码的另一种方法是通过使用 Object Level Trace（OLT）工具。OLT 通过生成应用程序组件交互的跟踪图为分布式应用程序的可视化执行提供手段。同客户机应用程序从 servlet、JSP、EJB 以及 Java/C++ 对象请求服务一样，OLT 使其能够跟踪它们。所跟踪的应用程序可能使用多种语言，被分布于网络，这对 OLT 来说就如同是本地一样。这意味着，如果应用服务器上有一个 servlet，该 servlet 调用在不同的应用服务器上 EJS 容器中运行的 EJS，可能在复杂的 n 层应用中可以找到，OLT GUI 将使您在不同的服务器之间收集可用的信息。这使您能够对程序进行分析，当它正在运行时，以便理解其动态特性以及诊断瓶颈。

OLT 有三个组件：

• OLT 服务器（OLT Sever）运行在单机上，从不同的应用程序中收集跟踪信息。
• OLT 引擎（OLT Engine）运行在要调试的每个应用程序中。该 OLT 引擎必须能够定位 OLT 服务器，使其能够发送跟踪信息，并且它也提供管道，发出调试命令。
• OLT 查看器（OLT Viewer）连接到 OLT 服务器并且象启动调试器那样能够向您显示跟踪的详细信息。

对于简单的情况，您可以启动 OLT 查看器，并且让它启动在同一台机器上的 OLT Server。配置 WebSphere Application Server，使其启动能够定位 OLT 服务器的 OLT 引擎。更复杂的情况在 更复杂的 OLT 情况章节中涵盖了。

要启动 OLT 查看器，在命令提示符状态运行命令 C:\ibmdebug\olt 。当 OLT 启动，它同时启动查看器和服务器，并且如下面的图 12 所示显示客户机控制器页面。为了指定 OLT 查看器不仅跟踪应用程序而且让我们对应用程序进行调试，将 Execution mode 设置为 Trace and debug。

当以跟踪和调试方式运行，OLT 查看器使您能用 Distributed Debugger 用户界面调试 WebSphere Application Server JVM。当打开 OLT 查看器，它将启动 OLT 服务器，接着下一步是启动 WebSphere Application Server，使它启动其连接到 OLT 服务器的 OLT 引擎。

回页首

通过 OLT 启动 AEs

为了通过 OLT 来启动 AEs，使用 -oltEnable 选项。如果服务器已经在运行，用 stopserver 命令终止它，然后用选项 -oltEnable 启动它，如果您希望和跟踪一样进行调试，使用 -debugEnable 选项。OLT 引擎在 WebSphere Application Server 内启动之后，必须定位 OLT 服务器，使其能够发送跟踪信息。要提供这种信息，使用参数 -oltHost 给出正运行 OLT 服务器的机器名称，使用参数 -oltPort 给出 OLT 服务器侦听的端口号。端口号缺省为 2102，可以在 OLT查看器 Preferences 页面进行配置。下面的图 13 展示了通过启用调试和启动 OLT 引擎启动 WebSphere Application Server 以及寻找并使用端口 2120 连接在机器 JoeWin.raleigh.ibm.com 上的 OLT 服务器：

如果您没有指定上面的任何选项运行 startserver 命令，它将使用来自配置 XML 文件 ? server-cfg.xml 的缺省值。管理控制台使您能使用浏览器 GUI 浏览和改变配置中的值。下面的图 14 展示了让您改变 OLT 和 Distributed Debugger 设置的页面。请注意图 14 和图 13 中的 hostName 都是正运行 OLT 服务器机器的名称，而不是运行 WebSphere Application Server 的机器名称。

虽然管理控制台没有必要强制源文件路径字段（即使是 OLT 没有启用时），该字段只有在通过使用 OLT 进行调试时是适用的。如果您输入一个无效的源文件路径，服务器将不能正确启动，因此您必须输入有效的路径，即使它只是 C:\temp 。当 Debugger 到 WebSphere Application Server VM 的连接建立，源文件路径信息被传给 Debugger，并且连同它自己的源文件搜索路径用来定位源文件。

回页首

通过 OLT 启动 AE

要启用 OLT 来启动 AE，您必须使用管理控制台。通过 OLT 调试有两个必需的步骤：必须启用 OLT，并且必须启用调试。您可以使用下面图 15 所示的 Advanced JVM settings。在这个对话框中，选中 Enable IBM Distributed Debugger和使 Enable debug mode不选中。这可能容易混淆，因为它看似您禁用了调试。但是选项 Enable IBM DistributedDebugger实际上意味着，“启用 IBM Distributed Debugger，使之用在使用 OLT 的配置中。”当 OLT 引擎在 WebSphere Application Server 内执行，它与它的 OLT 服务器进行通信。如果 OLT 服务器有一个以调试方式配置的 OLT 查看器与之相连，它将使用 OLT 引擎建立到 WebSphere Application Server JVM 的专有连接，并且对于 Debugger 作为调试代理。因此不使用允许 JPDA 套接字对 JVM 进行调试的传统调试设置，Enable Debug 方式复选框不用选。

在图 15 上，您也可以输入 Distributed Debugger 所使用的源文件搜索路径。选中 Enable IBM Distributed Debugger自动启用 OLT（如果它还没有启用）。

为了给 OLT 配置进行设置，在如下面的图 16 所示的管理控制台中的服务器上选择 Services标签。这将显示服务列表 ? 选择 OLT Service 并且编辑其属性，将让您输入 OLT 服务器主机名、OLT 服务器端口以及启用或禁用 OLT。

回页首

使用 OLT 和 HitCount 应用程序的示例

前面的两节展示了怎样配置 WebSphere Application Server，使它将在启动 OLT 引擎时运行。

以跟踪和调试方式启动 OLT 查看器后，启动 WebSphere Application Server，它已配置为启用了 OLT。然后通过打开浏览器为 http://localhost/HOSTNAME/examples/HitCount运行 HitCount 示例。最先是对 HitCount servlet 的调用，OLT 查看器将打开如下面的图 17 所示的窗口。要调试 HitCount 类，选择它并且单击 OK，否则单击 Cancel。

如果您选择 HitCount 类并且单击 OK，OLT 查看器将启动 Debugger 并且在入口方法（即 service(HttpRequest,HttpResponse) ）处停止。如果 Debugger 在管理控制台指定的路径为找到源文件 HitCount.java ，那么 Debugger 将在方法上直接打开，否则它将提示输入源文件位置。要继续运行这个应用程序，单击 Run，下一个程序调用将在 OLT 查看器的方法断点对话框中出现。这是对由 HitCount.jsp 页面创建的 servlet 的调用。在 Debugger 停止之后，您已经完成检查程序或单步调试代码，单击 Run继续运行 WebSphere ApplicationServer 应用程序。如果您不想在 WebSphereApplication Server 内继续调试，单击 Detach。

在完成了使用 OLT 的调试方案之后，查看器将向您展示被跟踪会话的历史记录。下面的图 18 以 HitCount servlet 和 JSP 页面之间调用显示了该历史记录。它象是出现在这一端的事件跟踪图，以类为行、每一列为程序间的调用。即使没有指定调试方式，当 OLT 查看器只用来进行跟踪时，参阅 WebSphere Application Server 内的程序调用的图形化图片对于理解您想要调试应用程序的动态特性是有很大帮助的，OLT 查看器是非常有用的分析工具。

回页首

更复杂的 OLT 情况

在上面的章节中，启动了 OLT 查看器以及配置了 WebSphere Application Server，使它的 OLT 引擎按照其 oltHostName 连接到查看器的机器。实际是通过 OLT 查看器自动启动 OLT 服务器，OLT 引擎与之进行通信。要查看这些，在如上面的图 12 所示的 OLT 查看器配置设置对话框的 File 菜单，打开 OLT 查看器上的 Preferences窗口。这将打开显示 OLT 服务器主机名（缺省值为 localhost）以及 OLT 端口（缺省值为 2102）的浏览器参数对话框。当服务器的主机名是 localhost 时，OLT 查看器当它被启动时自动启动 OLT 查看器。OLT 查看器浏览器参数的端口号 2102 是正运行 OLT 服务器机器的端口，该服务器 WAS 运行时引擎将用来与之进行通信。

不用 OLT 查看器启动 OLT 服务器。可能您希望 OLT 服务器在它自己专用的机器上独自运行，然后 OLT 查看器将远程连接到该机器。如果您想这样做，您应该在 OLT 查看器浏览器参数对话框将主机名改为要启动 OLT 服务器的机器，然后退出 OLT 查看器。在正运行 OLT 服务器的机器上使用命令 oltsrv-standalone ，然后启动 OLT 查看器。这将定位并连接 OLT 服务器。

图 12 中的 OLT 查看器客户机控制器对话框展示了调试器主机名和端口名。如果这些与正运行 OLT 查看器的机器相同，那么 OLT 查看器将启动 IBM DistributedDebugger。如果您想在另一台机器上运行调试器用户界面，您应该在那台机器上手工输入命令 idebug -qdaemon -quiport=nnnn 人工启动调试器守护程序，然后在客户机控制器页面指定该机器名和 nnnn 端口号。

回页首

总结

这篇文章论及了怎样调试在 WebSphere Application Server 内运行的 Java 代码，比如 servlet、EJB 或 JSP。它涵盖了 AE 和 AEs，直接将 Debugger 连接到 WebSphere ApplicationServer 或通过 OLT 间接连接。此外还包括 IBM Distributed Debugger 和 OLT，WebSphere 4.0 引入了新的 WebSphere Studio Application Developer 工具套件，它集成了 IBM 开发工具以及更紧密相关的工具。以后的文章将向您展示怎样用 WebSphere Studio Application Developer 完成调试和跟踪查看。我们希望您能觉得这篇文章有用，我们欢迎所有的反馈信息。

关于作者

		Joe Winchester 是北卡罗莱纳州的为 Research Triangle Park 的软件解决方案组（Software Solutions group）服务的 WebSphere 工具开发小组（WebSphere Tools Development team）的成员。他从事于两种 VisualAge 持久性特征的研究：Object Extender for Smalltalk 以及 Persistence Builder for Java。您可以通过 joewin@us.ibm.com和 Joe 联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首