在每个专栏中，支持权威将讨论 IBM Technical Support 的可用于 WebSphere 产品的资源、工具和其他元素，以及一些可以进一步增强您的 IBM 支持体验的技术和新思想。

最新快报

按照惯例，我们将首先提供关于整个 WebSphere® 社区的一些重要新闻：

• IBM Support Assistant 的 4.0.1 版 刚刚发布。部分主要增强功能包括代理服务器的自动配置、改进的导航，以及一个重要的新工具：Media Viewer，此工具使得从诸如 IBM Education Assistant 等来源下载丰富的内容并在 IBM Support Assistant 中在线或离线查看该内容变得非常容易。
• IBM Support Assistant Version 4 中发布或更新了几个新工具，包括：
  • Assist On Site
  • IBM Thread and Monitor Dump Analyzer
  • IBM Monitoring and Diagnostic Tools for Java™ - Dump Analyzer 的新版本
  • 对 Memory Dump Diagnostic for Java (MDD4J) 的新更新；此更新仍处于测试版本阶段，但是我们正在向公开发布版迈进。
  • Visual Configuration Explorer (VCE) 的新更新。

  通过这些更新，要从 IBM Support Assistant Version 3 移植到 Version 4 的所有问题确定工具都已完成了转换。

• IBM Guided Activity Assistant 团队继续扩展此工具所提供的内容：
  • 最初于上月在 IBM Guided Activity Assistant 的 alphaWorks 版本中宣布推出的用于 JVM 问题确定（挂起、崩溃、内存耗尽等等）的增强内容现在也在 IBM Support Assistant 上可用。
  • 用于 WebSphere Process Server 中的问题确定的新内容将于本月在 IBM Support Assistant 上的 IBM Guided Activity Assistant 中首次露面。
  • 对 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV) 和 IBM Thread and Monitor Dump Analyzer (TMDA) 工具使用指导的若干更新。
• 还发布了对 alphaWorks 中的几个工具的更新，包括：
  • Database Connection Pool Analyzer for IBM WebSphere Application Server
  • IBM Thread and Monitor Dump Analyzer（也在 IBM Support Assistant 中可用）
  • IBM Pattern Modeling and Analysis Tool for Java Garbage Collector（也在 IBM Support Assistant 中可用）。
• 对于感兴趣的读者，WebSphere Application Server V7.0 公开测试计划正在全力进行中。访问此站点以了解有关下一个版本的 WebSphere Application Server 的新闻和信息。
• 我们在以前的几篇文章中推荐过的 WebSphere Support Technical Exchange 系列正在对新的“Open Mic”形式进行试验，在这种形式中，某个特定技术领域的公认专家将接受问题并主持与受众进行的讨论，而不是主要集中于已准备好的演示文稿。这种新形式的第一期暂定于 8 月 7 日进行，届时还将有关于 WebSphere Application Server 安全性的研讨会。请回访 WebSphere Support Technical Exchange 网站以了解更新和更多的研讨会。
• 我们以前曾在本专栏中提到过知识集锦（在 IBM Support 网站上创建相关文档的集合）和特色文档（收集用于每个单独 IBM 产品中的支持的最常见信息）。将这两个概念相结合，现在可以使用新的知识集锦，从而使得完全在单个位置查找许多 WebSphere 产品的所有可用特色文档页面变得非常容易。
• 本专栏的热心读者可能对红皮书 Running IBM WebSphere Application Server on System p and AIX Optimization and Best Practices 非常感兴趣，该红皮书目前以公共草案的形式提供。

继续关注与支持相关的各个网站以及本专栏，以获得有关我们所碰到的其他工具的新闻。

接下来让我们继续今天的主题……

回页首

“再多一个工具我就要尖叫了”

我们在与 WebSphere 产品用户进行有关问题确定的交谈时，遇到的一个常见问题是“我现在应该使用哪个工具？”本专栏自从开始以来，已描述了如何以及何时使用许多问题确定工具，但是如果像这样一次一个地介绍工具，跟踪每个可用的工具将会充满了挑战，要确定哪个工具最适合于任何给定的情形就更不用说了。由于更广大的 IBM WebSphere Support 社区是相当动态的工具开发人员社区这一事实，问题变得进一步复杂化，这意味着可用的工具集始终变化不定，针对相似的问题，某一天使用的最佳工具可能在几个月后已经不一样了。

我们的希望在于，本文将为您阐明某些目前可用的主要问题确定工具。您将在下面找到简单的参考表格，其中在单个地方显示了您在与 WebSphere Support 合作时可能遇到的最常见问题确定工具，特别是有关 IBM WebSphere Application Server 和 Java 虚拟机（Java Virtual Machine，JVM）的工具。这些表格并不详尽，所提供的信息在性质上是不完美的——因为在本文发表之后，工具将继续发展改进，并且不同的人将以不同的方式评价各个工具。然而，不管您最终使用的工具是什么，此信息都可作为有价值的初始参考点。如果您碰巧发现这种方法很成功，请告诉我们，以便我们能够为今后的专栏计划定期的更新。

回页首

我们选择的工具

在接触到具体的表格之前，检查一下我们在组合这些信息时使用的指导原则是有帮助的：

• 可用性

  与 IBM Support 组织直接或间接提供的大多数问题确定资源一样，本文专门集中于可从 IBM 免费获得的工具。这并不是说不存在其他工具；IBM（特别是 Tivoli®）和其他软件供应商提供了各种收费的问题确定工具，您可以使用它们来调查 WebSphere 问题。其中有些工具提供的功能远远超出了这里提到的免费工具的范围。然而，就本文的目的而言，以及为了确保每个人都有访问这些资源的同等能力，这些表格省略了商业化的工具。

• 可访问性

  在评估问题确定工具时，IBM 将考虑所有的相关候选工具，而不管这些工具驻留在何处。不过在一般情况下，IBM Support 仅收集 IBM Support Assistant 提供的公共平台中的独立工具（除非存在收集其他工具的技术原因）。IBM Support Assistant 是中央存储库，目前用于查找所有的工具、用于安装和接收现有工具的定期更新，以及用于利用多个工具和其他问题确定功能之间的集成潜力（例如，将工具与诊断收集和 PMR 报告功能联系起来，或者将一个工具的输出作为输入提供给另一个工具，等等）。

• 范围

  这里列出的工具仅限于客户和 IBM Support 团队经常用于在活动中帮助分析问题确定构件的工具，而不包括收集问题确定构件或者指导或全面帮助问题确定过程的工具。

• 用于相同用途的多个工具

  随着工具的发展和新工具的出现，在最大限度地促进创新的名义下，以及为了鼓励许多感兴趣的工具编写人员做出贡献，必定存在功能上的重叠。因此，您将发现这些表格中有些地方列出了用于同一个目的的多个工具。在这些情况下，将提供有关这些工具之间的重要区别的信息，以帮助您挑选最适合需要的工具。一般情况下，将会有一个工具被标识为主要工具（用粗体字型表示），我们估计它是您在尝试执行特定问题确定任务时最适合首先尝试的工具。然而，如果您具有对另一个工具的特定特征的特殊需要，您也可以使用替代工具。一般来讲，IBM Support 主要致力于对每个领域中指定的主要工具进行增强和支持，并且随着时间的推移，将会尽量把替代工具中有价值的新功能合并到主要工具中。

• 支持

  虽然我们希望使新的工具和新的工具功能尽快可用，但这有时意味着在编写它们之后随即“按原样”使它们可用。另一方面，我们认识到许多用户想要并且需要可靠和可信赖的工具IBM WebSphere Support 提供的每个工具与许可协议相关联，许可协议定义了该工具是否受支持的条件。（不得将本文中的任何信息理解为覆盖或取代任何许可协议中提供的信息。）不过在一般情况下：

  • 通过 IBM Support Assistant 交付但指定为技术预览版的工具以及通过 alphaWorks 交付的工具被认为是“按原样”提供的。如果取得了成功并得到广泛使用，许多起初以这种方式发布的工具（虽然不一定是全部）最终将成为受支持的标准工具。这些工具一般是非常优异的，如果没有更好的替代工具可用，您可以非常舒适地使用它们。
  • 通过 IBM Support Assistant 交付并且未指定为技术预览版的工具在其许可协议规定的条款下受到正式支持（由它们的创作者或 IBM WebSphere Support 提供支持）。IBM 一般为受支持的工具提供了帮助和缺陷报告。
• 问题与功能

  下面的表格主要按照它们读取的构件类型进行组织。其中也列出了可以使用每种构建分析来确定的问题类型。在调查某个问题时决定如何进行的时候，务必记住这一点。当您需要快速参考的时候，这种以构件为中心的视图通常非常有用；例如，您面对某种特定类型的日志或转储文件，并且您需要快速查找某个可用于分析该文件的工具。然而，以前的“权威支持”专栏用事实证明，要提高效率，问题确定过程应该遵循定义良好的计划，该计划基于问题症状及其可能的根源，并且不执行随机操作或者“只是因为那些构件存在”而分析各个构件。无论是哪种方式，这些表格都应该能够帮助您。

  或者，您可能希望利用 IBM Guided Activity Assistant 或以前的专栏中提到的其他某个问题确定指导资源，以帮助您决定何时检查每个构件和使用每个工具可能是最高效的。

下面几个部分中的工具表格将按照它们所用于的构件进行组织：

• 用于 JVM 生成的信息的工具
• 用于日志和跟踪文件的工具
• 用于静态配置文件和相关信息的工具。

每个表格后面是每个工具自己的文档中对每个工具的描述，以及每个工具的一般特征的大致细分。

回页首

用于 JVM 生成的信息的工具

此类构件包括：

• Verbose Garbage Collection (verboseGC) 日志也许是最常见的 JVM 诊断类型。它显示了整个 JVM 生存期间，各个垃圾回收周期的顺序。它作为确定问题时的一项初始的辅助工具，常常具有不可估量的价值，用于检测和诊断反常的内存分配问题，例如内存泄漏、碎片，以及与 GC 有关的性能问题等等。

• 线程转储也是一种极为常见的 JVM 诊断类型。线程转储（也称为 javacore）可以根据管理员的请求触发，或者在 JVM 中遇到某种特殊情况时自动触发。线程转储是一个文本文件，其中包含 JVM 状态的关键方面的一个相对较短的快照。该快照最常用的部分是 JVM 中当前活动线程的列表，线程转储也因此而得名。线程转储最常见的用途是诊断 JVM 中出现挂起、变慢、崩溃或 CPU 占用率过高的原因。

• 堆转储是也可由 JVM 生成的另一种形式的转储，可以按需生成，也可以在满足特殊条件时自动生成。通常，堆转储通常是一个非常大的文件，其中包含当前 JVM 堆中所有对象的一个列表。它用于在出现内存不足的情况下执行深入分析。

• 系统堆或核心堆是开销最大的堆，但也是最完整的堆。它是一个巨大的二进制文件，反映了 JVM 进程的全部内容：每一个 Java 对象及其字段、每一个线程、每个内存区域，等等。系统转储的最初用途是在其他类型的转储不足或无法生成时，帮助诊断崩溃、挂起或复杂的内存分配问题。不过，由于系统转储非常完整，它也能用来获取有关 WebSphere Application Server 运行时当前状态的多方面信息，甚至有关在该运行时中执行的应用程序的信息。

这里的有些构件的名称和类型特定于 IBM JDK；其他供应商的 JDK 可能产生相似的文件。有关这些类型的构件的进一步详细信息，请参阅“权威支持”专栏用于实际故障诊断的功能和工具。

表 1. 用于 JVM 生成的信息的工具

工具描述

用于 VerboseGC 分析：

1. IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV)
   一个详细的 GC 数据可视化器，用于分析并绘制所有 IBM 详细 GC 日志——Xtgc 输出（并且可扩展到分析和绘制其他形式的输入）。它提供了广泛的详细 GC 数据值的图形显示，并处理 optthruput、optavgpause 和 gencon GC 模式。它具有原始日志、表格式数据和图表视图，并且可以将数据保存到 jpeg 或 .csv 文件（用于导出到电子表格）。

   请参阅 IBM Support Assistant 中的完整描述。
   输入：verbosegc 日志
   输出：图形表示形式、html、jpeg 或 csv 文件
   支持：此工具由 IBM 提供支持，目前是用于其所在领域的主要工具。

2. IBM Pattern Modeling and Analysis Tool (PMAT) for Java Garbage Collector
   分析 IBM 详细 GC 跟踪，分析 Java 堆使用情况，并基于 Java 堆使用情况的模式建模提供重要配置建议。此工具先于上面的 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (1)，并提供了一个可能相当有用的不同透视图。

   请参阅 IBM Support Assistant 或 alphaWorks 中的完整描述。
   输入：verbosegc 日志
   输出：verbosegc 日志的图形或表格表示形式
   其他功能：关于 JVM 参数的一般建议
   支持：技术预览版，按原样提供。

3. Diagnostic Tool for Java Garbage Collector
   通过读取详细垃圾回收的输出，并产生文本和图形可视化表示形式及相关统计信息，从而帮助检查运行在 JVM 下的应用程序的垃圾回收特征。

   请参阅 alphaWorks 中的完整描述。
   输入：verbosegc
   输出：文本和图形可视化表示形式
   支持：按原样提供的工具。

用于 Java 转储/javacore：

4. IBM Thread and Monitor Dump Analyzer (TMDA)
   分析一个或多个 Java 线程转储或 javacore，并诊断监视器锁和线程活动，以便确定挂起、死锁和资源争用或监视器瓶颈的根源。

   请参阅 IBM Support Assistant 或 alphaWorks 中的完整描述。
   输入：用于显示相关线程历史记录的单个或多个 javacore
   输出：基于 GUI 的视图
   其他信息：关于 Analysis of hangs, deadlocks, and resource contention or monitor bottlenecks using IBM Thread and Monitor Dump Analyzer for Java Technology 的网络广播
   支持：技术预览版，按原样提供，但是是该领域的主要工具。

5. ThreadAnalyzer
   提供 Java 线程转储或 javacore 的分析，例如来自 WebSphere Application Server 的转储或 javacore。可以在不同的级别分析线程使用情况，从高级图形视图开始，然后深入到各个线程的详细记录。如果线程转储中存在任何死锁，ThreadAnalyzer 将检测并报告它们。此工具先于上面的 IBM Thread and Monitor Dump Analyzer 工具 (4)，但是其功能已集成到后者之中，后者正在成为该领域的主要工具。

   请参阅 IBM Support Assistant 中的完整描述。
   输入：Java 线程转储/javacore
   输出：线程的图形视图、加载多个线程转储以显示线程历史记录的能力
   支持：技术预览版，按原样提供，但是是该领域的主要工具。此工具可能会逐步淘汰；请尽可能使用 IBM Thread and Monitor Dump Analyzer。

用于线程：

6. IBM Lock Analyzer for Java
   旨在对动态应用程序执行锁分析，以便突出具有可能影响性能的锁争用的线程。此工具由两个包组成：

   • 第一个包与平台相关，并提供到 JVM 的连接，以便收集有关正在运行的应用程序的锁统计信息。这个包在运行时随同要监视的应用程序一起进行加载。
   • 第二个包与平台无关，并提供了图形用户界面。

   该图形用户界面连接到平台包，并提供所需的控制和分析以确定性能糟糕的锁。

   请参阅 alphaWorks 中的完整描述。
   输入：从 JVM 收集的统计信息
   输出：锁的图形视图
   支持：按原样提供的工具。

用于堆转储：

7. Memory Dump Diagnostic for Java (MDD4J)
   分析正在运行 WebSphere Application Server 或任何其他独立 Java 应用程序的 JVM 中常见格式的内存转储（堆转储）。内存转储分析旨在确定 Java 堆中可能是内存泄露根源的数据结构。该分析还确定应用程序的 Java 堆占用空间的主要肇事者和它们的所属关系。此工具能够分析从遇到 OutOfMemoryError 问题的生产环境应用程序服务器中获得的非常大的内存转储（将需要 2 GB 或更多的 RAM）。MDD4J 扩展了下面较旧的 IBM HeapAnalyzer (8) 的功能，尽管两个工具的用户界面完全不同。

   请参阅 IBM Support Assistant 中的完整描述。
   输入：来自虚拟机 (JVM) 的内存转储（堆转储）
   输出：交互式报告，其中显示主要的内存泄露可疑之处，以及有关这些泄露的详细信息。
   其他功能：操作单个转储。有些版本提供了多个转储的比较分析。
   支持：此工具由 IBM 提供支持，目前是用于其所在领域的主要工具。在本文编写之际，IBM Support Assistant 中的最新版本为 Beta 版。

8. HeapAnalyzer
   HeapAnalyzer 读取单个 Java 内存转储（堆转储），并使您能够浏览转储以查看其内容。此工具是上面的 Memory Dump Diagnostic for Java (MDD4J) 工具(7) 的前身，后者现在包含前者的大多数功能。当时，HeapAnalyzer 中的原始树浏览功能比在 MDD4J 中更加灵活。另一方面，HeapAnalyzer 缺乏 MDD4J 中的某些更完善的泄露嫌疑检测算法，并且不支持多个转储的比较分析。

   请参阅 alphaWorks 中的完整描述。
   输入：单个 java 堆转储
   输出：可疑对象的图形视图和堆浏览器
   支持：按原样提供的工具。

9. HeapRoots
   HeapRoots 读取 Java 堆转储文件并提供用于分析数据的命令。这些命令对数据运行算法，或查询有关该数据的信息。HeapRoots 提供了命令行交互式界面，您可以在其中输入命令并获取结果。

   请参阅 alphaWorks 中的完整描述。
   输入：堆转储文件
   输出：可疑对象的图形视图和堆浏览器
   支持：按原样提供的工具。

用于系统/核心转储：

10. IBM Monitoring and Diagnostic Tools for Java - Dump Analyzer
    一个可扩展的工具框架，它读取 IBM JVM 产生的系统转储或核心文件，并针对该转储运行各种各样的分析模块以诊断常见问题，或提供有关该 JVM 和当前运行在该 JVM 中的任何中间件或应用程序的内部状态的深入信息。目前，提供了用于对诸如死锁、挂起、崩溃、内存情况等常见 JVM 问题执行基本分析功能的模块。作为对该基本工具的补充，WebSphere Applicationi Server Modules for Dump Analyzer 提供了附加的模块，可显示 JVM 中的 WebSphere Application Server 运行时的一般状态，以及有关多个 WebSphere Application Server 子系统的详细信息。

    请参阅 IBM Support Assistant 中的完整描述。
    输入：由 JVM 附带的 jextract 工具进行预处理的格式化系统转储
    输出：显示一个报告，其中包含由指定的分析模块提取的信息，还包含有关潜在问题的观察结果的简短摘要，以及一个提供深入信息的详细信息部分。
    其他功能：提供交互式模式以手动检查转储的内容。使得用户能够编写自己的新的专门分析模块并将模块添加到该工具。
    支持：此工具由 IBM 提供支持，目前是用于其所在领域的主要工具。

回页首

用于日志和跟踪文件的工具

用于这些类型的构件的活动包括：

• 日志记录通常用于在日志文件中记录您希望跟踪的重要事件。日志记录用于指示：

  • 重要的状态更改；例如，当某个服务启动或停止的时候。
  • 警告；例如，当您正在写入的磁盘空间不足的时候。
  • 错误；例如，当您的代码由于预期的服务不可用而不再能够继续执行的时候。

  日志记录通常是始终启用的，因此日志记录代码必须体积相当小，这通常是您应该注意的重要事项。

• 跟踪通常用于记录在调试代码问题时可能有用的任何信息。跟踪通常用于指示调用了哪些方法、向方法传入了哪些数据（或从方法返回了什么值）以及对代码边界之外的其他方法的调用返回了什么数据。跟踪事件体积可能比较大，因此只有在诊断问题时启用。由于跟踪事件的内容极为详细，而且是技术信息，因此经常只对编写应用程序的人有价值。打开跟踪的情况下，应该能够了解在代码中可能出现的任何问题。

表 2. 用于日志和跟踪文件的工具

工具描述

11. Log Analyzer（以及相关的 Symptom Editor）
    一个图形用户界面，提供用于浏览、分析和关联多个产品产生的日志的单个联络点。此工具是更广泛的 IBM 自主计算活动的一部分。

    请参阅 IBM Support Assistant 中的完整描述。
    输入：来自 IBM 和其他供应商推出的许多软件产品的多个日志文件
    输出：基于 GUI 的视图和日志文件关联
    其他功能：能够保存配置以帮助其他支持工程师进行进一步的分析。提供了配套的 Symptom Editor 工具来创建您自己的症状数据库。
    支持：目前是其所在领域的主要工具。

12. Trace Analyzer for WebSphere Application Server
    一个高度交互式的实用工具，使您能够详细浏览、检查和搜索 WebSphere Application Server 中的复杂跟踪文件。

    请参阅 alphaWorks 中的完整描述。
    输入：WebSphere Application Server trace.log；如果启用了高级日志记录，则还支持更多的输入
    输出：功能强大的图形视图，带筛选器和搜索视图
    其他功能：能够保存配置以帮助其他支持工程师进行进一步的分析
    支持：按原样提供，但目前是其所在领域的主要工具。

13. IBM Trace and Request Analyzer for WebSphere Application Server
    帮助查找非正常延迟、系统运行缓慢或系统表现为挂起然后又恢复的情况的根源。此工具检查 WebSphere Application Server 和 HTTP 插件中的跟踪文件，通过这些文件确定各个请求，并找出特定操作需要花长时间完成的区域，从而帮助您检查跟踪中的可疑区域，以确定是否存在问题。用户有时将此工具与上面的 Trace Analyzer for WebSphere Application Server (12) 搞混淆，但事实上它们是完全不同的。此工具严格地集中于尽可能自动地找出性能问题和延迟，而 Trace Analyzer 是通用工具，主要用于手动检查跟踪。

    请参阅 alphaWorks 中的完整描述。
    输入：HTTP 服务器日志 (http_plugin.log) 和 WebSphere Application Server 跟踪日志 (trace.log)
    输出：表格分析视图
    支持：按原样提供，但目前是其所在领域的主要工具。

14. Database Connection Pool Analyzer for IBM WebSphere Application Server
    采用启发式分析引擎来帮助您解决与 Java Database Connectivity (JDBC) 连接池相关的问题，并诊断 JDBC 连接泄露。此工具分析 JDBC 连接池管理器跟踪，并提供以下功能：

    • JDBC 数据源分析。
    • JDBC 连接池配置分析。
    • JDBC 连接图表视图。
    • getConnection 方法的 Java 堆栈跟踪视图。

    有关使用此工具分析连接池问题所需要的 WebSphere Application Server 跟踪设置，请参阅 MustGather 信息。

    请参阅 alphaWorks 中的完整描述。
    输入：JDBC 跟踪日志
    输出：日志的表格和图形分析
    支持：按原样提供，但目前是该领域的主要工具。

回页首

用于静态配置文件和相关信息的工具

表 3. 与静态配置相关的文件

工具描述

15. Visual Configuration Explorer (VCE)
    提供一种可视化、探索和分析不同来源的配置信息的方法，例如 WebSphere Application Server、WebSphere MQ 和 DB2。此工具允许您：

    • 比较相同运行时环境的不同快照。
    • 创建图表，采用图形格式显示配置信息，包括配置元素之间的主要关系。
    • 访问详细的配置属性。
    • 在配置内和跨配置搜索属性。
    • 比较配置。
    • 在不同的产品的配置信息之间建立联系。
    • 保存和恢复工作。
    • 在问题确定工作中与其他人进行协作。
    • 在独立环境或客户机/服务器环境中工作。

    请参阅 IBM Support Assistant 中的完整描述。
    输入：从 VCE 附带的 VCE 远程收集器工具中产生的 JAR 文件
    输出：配置的图形描述。配置的差异报告（保存为 XML 格式）
    其他功能：能够保存配置，以帮助其他支持工程师进行进一步的分析。提供了配套的 Symptom Editor 工具来创建您自己的症状数据库。
    支持：技术预览版，但它是其所在领域的主要工具。

16. IBM Web Server Plug-in Analyzer for WebSphere Application Server
    帮助发现与 WebSphere Application Server 的 HTTP 插件组件相关的潜在问题。此工具同时分析插件配置和对应的跟踪文件，然后应用模式识别算法，以便向用户发出有关可能的不一致性的警报。此工具提供配置和跟踪文件中的 HTTP 返回代码列表、URI 和可用集群的图形表示形式，以及服务器拓扑。

    请参阅 alphaWorks 中的完整描述。
    输入：WebSphere 插件日志文件 (http_plugin.log) 和 WebSphere Application Server 跟踪文件 (trace.log)。
    输出：显示 plugin-cfg.xml 文件和 trace.log 分析中的集群和成员拓扑的可视映射。
    支持：按原样提供，但目前是其所在领域中的主要工具。

17. Configuration Validator
    此工具是 WebSphere 管理控制台的一部分，它帮助确定和查看 WebSphere Application Server 中的当前配置中存在的问题。

    请参阅 WebSphere Application Server 信息中心的完整描述。
    输入：操作 WebSphere Application Server 的某个运行实例，可通过管理控制台进行访问。
    输出：配置问题的表格视图（单独的错误、警告选项；管理控制台中可用的信息）。
    支持：包括为 WebSphere Application Server 的一部分，服从与主产品相同的支持流程。

18. Classloader Viewer
    提供 WebSphere Application Server 的某个实例中当前活动的所有类加载器和它们已加载的所有类的详细清单。这可以帮助诊断一系列与类加载相关的问题，例如未能加载所需的类、加载了某个类的意外版本、多个类之间的可见性问题，等等。

    请参阅 WebSphere Application Server 信息中心的完整描述。
    输入：操作 WebSphere Application Server 的某个运行实例，可通过管理控制台进行访问。
    输出：WebSphere Application Server 管理控制台中的树形细分视图；可保存到文件以便以后分析。
    支持：包括为 WebSphere Application Server 的一部分，服从与主产品相同的支持流程。

19. Install Verification Utility (IVU)
    作为一个在 WebSphere Application Server 中可用的名为“installver”的程序来交付，此程序对构成当前 WebSphere Application Server 安装的文件执行校验和，并将校验和与 WebSphere Application Server 附带或在该工具以前的执行过程中生成的参考文件做比较。此工具帮助检测被破坏的安装，例如，可能安装了修改或修补程序然后却遗忘了。

    请参阅 WebSphere Application Server 信息中心的完整描述。
    输入：WebSphere Application Server 文件，使用 verifyinstallver.bat 或 .sh 运行该工具。
    输出：指示成功的文件检查的消息。
    支持：包括为 WebSphere Application Server 的一部分，服从与主产品相同的支持流程。

20. IBM Port Scanning Tool
    在产品的安装、配置或激活过程中扫描可用的端口，以帮助防止端口冲突。

    请参阅 IBM Support Assistant 中的完整描述。
    输入：要检查的端口号范围
    输出：列出任何正在使用的端口和任何可能的冲突的报告
    支持：技术预览版，但目前是其所在领域的主要工具。

回页首

总结

我们对用于 WebSphere 产品的一些最常遇到的问题确定工具的概述到此就结束了，并提供了一些帮助您确定何时最适合使用每个工具的信息。但愿此信息将帮助您迅速和尽可能高效地启动问题解决任务。请记住，IBM 提供的工具集在不断地发展和增加，因此务必定期检查有关每个工具的最新信息，并从问题确定工作的前沿返回到本专栏以了解更多新闻。

Assuming you are familiar with the basic concepts of XMLAccess, the following refinements to the process should be straightforward. Instead of taking a full export from your production environment, suppose you wish to only export the portlets? In XMLAccess, the portlet is represented by the object type "web-app." Naturally you could generate an export of the portlets using the following XML (which is included in the samples shipped with Portal):

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd" type="export">
    <portal action="locate">
        <web-app action="export"
          objectid="*"/>
    </portal>
</request>
By importing this xml file, we direct the portal to export only the web-app object called '*' which is a wildcard for all web-apps. The command would be as follows:

xmlaccess.bat -in C:\temp\export_all_portlets.xml -user wpsadmin -pwd wpsadminpwd -url http://portal.example.com/wps/config -out C:\temp\outputfile_all_portlets.xml

Right, so very easy. However, this sort of thing is useful only if we already have a portal configured with all of the portlets. If we're exporting all "web-app" objects, this assumes we have some to export in the first place. Suppose you have 50 new portlets that all need to be installed, but you have no existing portal that has all of them in place. Are you going to use the portal admin interface and click-click-click your way through installing 50 portlets, assigning permissions, creating pages, putting the portlets on the pages, etc. etc. etc.? Probably not - at least, I know I wouldn't.

How can we use XMLAccess to build a portal configuration if we are deploying portal elements for the very first time? This task won't involve exporting a config from somewhere, since we don't have things configured in any environment yet. Instead we're going to construct our XML files from scratch and import them into a blank portal in order to build our configuration.

The various XML files referred to from this point forward are printed at the end of this article.

The Blank Portal
When installing WPS, it is often desirable to deploy the portal without the sample pages and labels and portlets; it is simply too much clutter. To install a blank portal, use the following command when invoking the installation program:

install.bat -W installPortlets Sequence.active="false"

Proceed through the portal install sequence as you normally would. When complete, start the portal and go the portal home page. You should now see the blank portal.

Before continuing, be sure to have all of your necessary files in place. That is, if you are installing a theme, place the folder containing the theme on the PortalServer in the correct location. The same goes for skins, portlet WARs, etc.

Theme folders go into:
C:\WebSphere\AppServer\installedApps\<nodename>\wps.ear\wps.war\themes\html\

Skin folders go into:
C:\WebSphere\AppServer\installedApps\<nodename>\wps.ear\wps.war\skins\html\

By default, portlet WAR files need to be placed in:
C:\WebSphere\PortalServer\installableApps

With our blank portal installed, and with our component files in place, let's begin constructing our new portal. We'll start with the skins and themes.

Install Skins and Themes
The XML to install the theme will of course include the standard XML header for WPS 5.1. After that, we will do the required locate action on the "portal" object. After this we will instruct XMLAccess to perform an "update" on our skin with the parameters that we specify as show in Listing 1.

The skin object we specified includes the objectid, uniquename, and resourceroot parameters. Objectid will be the skin's referential id within the portal database. For ease of use, we also have a uniquename specified for this skin so that we can easily refer to the skin from this point forward. The resourceroot indicates the case-sensitive folder name of our skin that we placed in the skins\html\ directory.

Let's save this file as import_skins.xml. Once we import this file, we will have installed the skins into our portal:

xmlaccess.bat -in C:\temp\import_skins.xml -user wpsadmin -pwd  wpsadminpwd -url http://portal.example.com/wps/config

To install our themes, we need an XML file with similar information 

Since a theme has default and allowed skins assigned to it, we first have to find these skins before we can assign them to the theme. So we do a 'locate' on our two skins that were added in Listing 1. Once we find them, we perform an "update" on the theme object.

The update uses defaultskinref to define the default skin for the theme. For the first theme, we used Skin_A as the default skin. The objectid and uniquename for the theme are defined (and can be different, as indicated). The resourceroot is the case-sensitive folder name of the themes\html\ directory.

Notice that in addition to defining the default skin for each theme, we can also define the other skins that can be used with this theme. Notice that for Theme_Blue we are using Skin_A as the default, but we allow Skin_A as well as Skin_B. This is defined in the <allowed-skin skin="..."> section. Notice that for Theme_Green we are using Skin_B as the default and we only allow that skin. After all, Skin_A is red. Mixing a red skin with a green theme is just plain ugly.

Now let's save the xml file as import_themes.xml and import our themes into the portal configuration:

xmlaccess.bat -in C:\temp\import_themes.xml -user wpsadmin -pwd wpsadminpwd -url http://portal.example.com/wps/config
Install Portlets
We have our themes and skins imported, now let's put those pesky portlets in place.

Constructing the XML file for portlet install is a little trickier. It involves knowing some key information about the portlets. This information is found in the portlet.xml and web.xml inside the portlet.war file. For this step Winzip is especially useful, as you will need to be able to open the portlet WAR file (see Listing 3). You may also be able to get this info from the portlet developer. After all, he can see this info in his portal toolkit inside WebSphere Studio. However, developers being as busy as they usually are, good luck extracting this info from them.

Okay. This is slightly more complex. Here we have 3 portlets that we're installing. You can see we're locating the portal (of course), and then we do an update on object "web-app" which represents the WAR file.

The next parameter is the web-app uid parameter. The uid must match the uid attribute of portlet-app in portlet.xml in the portlet WAR file.

Following the uid, we have to specify the location of the portlet WAR file. When we transferred our portlet WARs to the server, we placed them in C:\WebSphere\PortalServer\installableApps. To refer to this location, we can use the $server_root$ variable which gets set when the XMLAccess interface is invoked.

Next, we have to perform an update on the portlet-app object. This represents the portlet application and is the parent of all the portlets contained within. The next parameter is the portlet-app uid parameter. The uid must match the uid attribute of concrete-portlet-app in portlet.xml in the portlet WAR file.

Finally we have the update to be performed on each portlet in the portlet application. In this example we only have one portlet in each WAR file, but we could potentially have several in each one. If this were the case, we'd have multiple "portal" objects defined within the "portal-app" object. We give the portlet an objectid and we define the name. The portlet name parameter must match the content of the portlet-name subtag of concrete-portlet in portlet.xml in the portlet WAR file.

So let's go ahead and save the xml file as import_portlets.xml and execute:

xmlaccess.bat -in C:\temp\import_portlets.xml -user wpsadmin -pwd wpsadminpwd -url http://portal.example.com/wps/config

We should now have deployed skins, themes, and portlets. Let's create a page and drop some portlets on it.

Create Pages
This is very straightforward. We need pages on which to place our portlets. Pages and labels are represented in the XML files as "content-node." Seems pretty logical if you think about it. A node of content. A content-node. Brilliant.

Our XML will look like Listing 4. Think of it logically. We first locate the resources we need (themes, portlets) and then we create our pages using those resources. Piece of cake. In this example, we'll create a label in the Content Root called Home (Content Root is the highest node of the content hierarchy. It exists by default). Hanging off this label is a single page called Welcome. On this Welcome page is single row containing our portlet, PortletCharlie.

You can see that we start off by locating the necessary resources - first the theme, Theme_Blue and then the portlet, PortletCharlie. Finally we have to locate the Content Root.

The next step in the process is to create the Home label. We give it an objectid and a uniquename. We define the content-parentref to be this label's immediate parent. In our case, this is the objectid of Content Root. Because we're creating a label at this point and not a page, we can assign a theme to the label. So we define themeref to be Theme_Blue.

Once created, we must immediately "locate" the new label before it can be used in the rest of the XML file. Next, we want to create the page called Welcome that is on the label called Home. You can see the values we use to define this page. With a page, however, we can also define the columns and rows containers that compose the structure of a portal page. Within these containers, we place the portlets.

The rows and columns on the page are defined in the "component" section in that page. In this example, within the page definition for the content-node Welcome, we define a component with an orientation of "H," which stands for horizontal, which is therefore a row. Setting the orientation to "V" would of course create a column. Rows can contain columns and vice versa. Tweaking these settings is how you could create an incredibly complex nested row/column page structure, if you so chose.

There are other parameters you can tinker with. Changing "ordinal" will change the order in which this content-node appears (since we only have one content-node at this level, it doesn't matter, but if we had a whole row of pages on the toolbar, we could order them using the ordinal parameter). Setting the "active" parameter to false would de-activate this content-node; and on and on...

<component action="update" active="true"  objectid="container1" ordinal="-1" orientation="H"  type="container" width="300">
 <portletinstance   action="update" handle=""  objectid="portletinstance1"portletref="Portlet_Charlie"></portletinstance>
</component>
Inside the component definition for the row on our page, you can see that we have put a portletinstance object with portletref set to Portlet_Charlie. This value must match the uid of the portlet that you wish to put in this container.

So here it is. Let's save this file as import_pages.xml and execute:

xmlaccess.bat -in C:\temp\import_pages.xml -user wpsadmin -pwd wpsadminpwd -url http://portal.example.com/wps/config
Once our import is complete, fire up a browser and go check out your brand new portal! Wunderbar! You should see your label with a page that has a portlet on it. Experiment.

Of course you can also go further and assign permissions to your objects using XML, or you could create XML files to remove portlets but leave the pages and so forth and so on.

Make liberal use of the example files in C:\WebSphere\PortalServer\doc\xml-samples, or the InfoCenter documents regarding XML Access. These pages are currently located at http://publib.boulder.ibm.com/infocenter/wp51help/topic/com.ibm.wp.ent.doc/wps/admxmlai.html.

下面是两个java读取JKS文件中密钥的方法

当然在看懂下面两个方法之前要对JKS文件的结构有所了解：

JKS文件就好像一个仓库，里面可以放很多的东西，这里只存放一类东西就是密钥，仓库当然会有一把锁，防范别人随便乱拿，这个就是JKS文件的密码。里面存放的密钥也各有不同，每个密钥都有一个名字（在下面叫别名），一类就密钥对，一类叫公钥，一类叫私钥，密钥对就是包含公钥和私钥的。这里的公钥只要你能进入仓库你就可以随便查看拿走，私钥则是有密码的，只允许有权限的人查看拿走。所以在下面读取密钥时也就有点细微的不同之处，对于读取公钥只需要知道JKS文件（仓库）的密码就可以了，但是在读取私钥时则必须有私钥的密码也就是你必须要有权限，在下面你会发现，在读取私钥时多了一个参数，对应的就是私钥的密码。

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.UnrecoverableKeyException;
import java.security.cert.CertificateException;

import javax.security.cert.Certificate;

public class JKSTesting {
 public static PublicKey getPublicKey(String keyStoreFile,
   String storeFilePass, String keyAlias) {

  // 读取密钥是所要用到的工具类
  KeyStore ks;

  // 公钥类所对应的类
  PublicKey pubkey = null;
  try {

   // 得到实例对象
   ks = KeyStore.getInstance("JKS");
   FileInputStream fin;
   try {

    // 读取JKS文件
    fin = new FileInputStream(keyStoreFile);
    try {
     // 读取公钥
     ks.load(fin, storeFilePass.toCharArray());
     java.security.cert.Certificate cert = ks
       .getCertificate(keyAlias);
     pubkey = cert.getPublicKey();
    } catch (NoSuchAlgorithmException e) {
     e.printStackTrace();
    } catch (CertificateException e) {
     e.printStackTrace();
    } catch (IOException e) {
     e.printStackTrace();
    }
   } catch (FileNotFoundException e) {
    e.printStackTrace();
   }
  } catch (KeyStoreException e) {
   e.printStackTrace();
  }
  return pubkey;
 }

 /** *//**
  * 得到私钥
  * 
  * @param keyStoreFile
  *            私钥文件
  * @param storeFilePass
  *            私钥文件的密码
  * @param keyAlias
  *            别名
  * @param keyAliasPass
  *            密码
  * @return
  */
 public static PrivateKey getPrivateKey(String keyStoreFile,
   String storeFilePass, String keyAlias, String keyAliasPass) {
  KeyStore ks;
  PrivateKey prikey = null;
  try {
   ks = KeyStore.getInstance("JKS");
   FileInputStream fin;
   try {
    fin = new FileInputStream(keyStoreFile);
    try {
     try {
      ks.load(fin, storeFilePass.toCharArray());
      // 先打开文件
      prikey = (PrivateKey) ks.getKey(keyAlias, keyAliasPass
        .toCharArray());
      // 通过别名和密码得到私钥
     } catch (UnrecoverableKeyException e) {
      e.printStackTrace();
     } catch (CertificateException e) {
      e.printStackTrace();
     } catch (IOException e) {
      e.printStackTrace();
     }
    } catch (NoSuchAlgorithmException e) {
     e.printStackTrace();
    }
   } catch (FileNotFoundException e) {
    e.printStackTrace();
   }
  } catch (KeyStoreException e) {
   e.printStackTrace();
  }
  return prikey;
 }

 public static void main(String[] args) {
  PublicKey publicKey;
  PrivateKey privateKey;
  
  publicKey=getPublicKey("C:\\aaa.jks","AAAAAAAA", "ibmwebspheremq");
  privateKey=getPrivateKey("C:\\aaa.jks","AAAAAAAA", "ibmwebspheremq","AAAAAAAA");
  
  System.out.println(publicKey.toString());
  System.out.println(privateKey.toString());
 }
}

WebSphere Application Server V6.1 for Windows
was.cd.6100.trial.base.windows.ia32.zip  (518.6MB)

以下下载均需IBM 官方账号登陆

IBM Download director：

Download director is required when downloading Common Criteria certified products.

https://www14.software.ibm.com/webapp/iwm/web/reg/download.do?source=was60&S_TACT=109BH33W&lang=en_US&S_PKG=win61&cp=UTF-8&&&&dlmethod=dd

HTTP 下载：

https://www6.software.ibm.com/sdfdl/v2/regs2/was60/was61/Xa.2/Xb.XZT0eQtlFEAtKGXnBl9SUC_lc7t2gur7TkGfwVu9dg/Xc.was61/was.cd.6100.trial.base.windows.ia32.zip/Xd./Xf.LPr.D1vk/Xg.5528606/Xi.was60/XY.regsrvs/XZ.3FTPmw76Xk9MVyoZYj0pxpNV5xA/was.cd.6100.trial.base.windows.ia32.zip

本文假设读者对WEB和portal及portlet有基本的了解。

一、开发环境

RAD 7.5 + Websphere Portal Server 7.0

二、开发目的

开发一个地址薄，用来记录姓名和地址。

三、开发过程

1.         创建一个portlet项目

选择File->New->Portlet Project，弹出如下所示的对话框：

  输入或选择以上信息后，单击Next按钮，弹出如下所示的界面：

为简便起见，只选择了view和edit两个模式。继续点击Next按钮弹出如下界面：

 取消第一个复选按钮的默认选择，点击Finish按钮完成项目的创建。

项目创建完成后，项目中会生成如下4个关键文件：

AddressBookPortlet.java是portlet的处理文件；

AddressBookPortletEdit.jsp对应portlet的编辑状态；

AddressBookPortletView.jsp对应portlet的视图状态；

portlet.xml是portlet的部署描述文件。

2.         增加姓名地址信息

修改编辑模式所对应的AddressBookPortletEdit.jsp文件，提供用户输入界面。

 
修改AddressBookPortlet.java中的processAction方法：

 编辑界面提交的姓名和地址作为名称/值对的形式保存在PortletPreferences对象中。

response.setPortletMode(PortletMode.VIEW)表示处理完edit模式后迁移到view模式以显示最新的地址信息。

3.         显示地址薄中的名称地址信息

由于名称/地址信息已经保存在PortletPreferences对象中，因此只需要从该对象中取出所有的名称/地址信息并显示出来即可。修改AddressBookPortletView.jsp：

4.         部署

启动PortServer，可能需要较长的时间。

选中服务器WebSphere Portal V7.0 at localhost，弹出如下所示的菜单：

 
点击Add and Remove Projects…，弹出如下所示的界面：

将AddressBookPortletEAR添加到右边列表框中。点击Finish按钮完成部署。

5.  运行

从浏览器地址栏输入URL：http://localhost:10039/wps/myportal，输入用户名和密码后进入如下所示的界面：

 
点击该portlet所在页面右上角处（用蓝色椭圆标出了），弹出菜单，如下图所示：

点击个性化菜单条，弹出增加地址界面：

输入姓名和地址，点击保存按钮，则跳转到显示页面：

至此，一个具有地址簿功能的portlet开发部署完成，在以后的portal页面中就可以使用该portlet了。

 http://www.puyufanyi.com/