在 WebSphere Studio Application Developer 中开发 J2EE 实用程序 JAR

简介
当在 J2EE 框架中开发应用程序时，经常需要第三方类或实用程序类。您可以将这些类存储在各种位置上，以便应用程序中的其余模块使用。本文研究了各个位置的优点和缺点，以及阐述了为何这些类通常被打包成 JAR 文件且放置到仅有的两个位置中某一个位置上。

如果开发 J2EE 应用程序的团队同时也是开发实用程序类的团队，那么接下来的问题是如何在相同的工作台（workbench）中管理、构建和测试两种代码集。在 WebSphere Studio Application Developer 中，您可以在 Java™ 项目中创建实用程序类，但如何才能定期对这些类通过 jar 打包并将其放到别处呢？因为 Application Developer 是构建在高度可扩展的开放源码 Eclipse 项目之上的，所以这不是个问题。本文介绍了一个简单插件，可以用来定期或自动将一个 Java 项目通过 zip 压缩进包含在另一个项目中的 JAR 文件。

注：这个附加的插件并非 WebSphere Studio Application Developer 的一部分，仅提供作为产品扩展特性的示例。它不被正式地支持，下载之前您应该阅读完整的许可证协议。使用的后果自负。

将实用程序类置于何处？
通过对应用程序服务器和 J2EE 规范的研究，发现可存储类的 5 个位置，以使 J2EE 应用程序中的模块找到它们。下面会对各个位置进行探讨，并对各个位置是否适合实用程序类进行了研究。

• 作为 Web 模块的 WEB-INF/classes 文件夹中的松散类。仅在相同的 Web 模块中才可见到这些类，而且通常这也不是一个有效的位置，因为类可能与包含它们的 Web 模块无关。
  
  
• 作为 Web 模块的 WEB-INF/lib 文件夹中的 JAR 文件。这是放置 Web 模块使用的实用程序类的好位置。然而，由于仅从 Web 模块内部才可见到这些 JAR 文件，对于由多个模块使用的 JAR 文件而言，这个位置并不好。
  
  
• 作为 EJB 模块中的松散类。尽管从其它使用清单（manifest）文件的模块中可见到这些类，但这也是个差强人意的解决方案，因为实用程序类可能与其它包含在 EJB 模块中的代码无关。
  
  
• 作为应用程序服务器的全局类路径（classpath）中的 JAR 文件或松散类。这看上去是个简单的解决方案，因为它使实用程序类对任何运行在服务器上的模块可见。但是，基于四种原因考虑，您应该避免使用该技术。
  
  
  • 可移植性? 由于要在应用程序服务器之外放置代码，因而必须同应用程序一起复制这些类或 JAR 文件。这种技术还需要对每个部署该技术的服务器全局类路径进行更改。因为每个应用程序服务器具有不同的类装入器，而这超出了 J2EE 规范的范围，每个服务器类型可能要求区别地处理这些类。
  • 可见性? 该技术使类对运行在服务器上所有应用程序都可见。即使仅有一个应用程序需要这些类，其它的应用程序也可能会不经意地使用它们。
  • 可维护性? 该技术强制运行在服务器上的所有应用程序使用相同版本的类。如果将某个应用程序的类升级为新版本，则必须升级和／或重新测试其它所有的应用程序。
  • 兼容性? 该技术不让应用程序使用由应用程序服务器或其它应用程序所使用的不同版本的任何类。
    
    
• 作为 Ear 应用程序中的 JAR 文件。这些类对应用程序中使用有效清单文件的任何模块是可见的。这通常是最佳的解决方案，因为它使类被打包进它们自身的 JAR 文件，而这些文件对应用程序中的任何模块都是可用的。这种解决方案使您无须忍受使用全局类路径带来的任何问题。

考虑到上述原因，通常应该将实用程序类打包成 JAR 文件，并且将它们放到 WEB-INF/lib 文件夹中，或者更可能的，直接将它们放到企业应用程序（Enterprise Application）中。但是，如果开发 J2EE 应用程序的团队同时也开发这些类时会发生什么呢？在 Application Developer 内，Java 项目被用来创建和构建实用程序类，而不断地通过 zip 压缩这些项目，然后将 JAR 文件导回到 EAR 项目就很困难。由于 Java 项目中实用程序类的变化，因而重新构建和维护 EAR 项目以便测试得以继续就很麻烦。

如果有关实用程序类的工作刚刚展开，那么最简单的解决方案可能就是将包含已编译类的文件夹放到应用程序服务器的全局类路径上（如果是 WebSphere 的话，可能是 ws.ext.dirs ）。这样就可以迅速地开发并且可能提供一个适当的临时解决方案。但是，当类已完成，考虑到上面给出的原因，您应该使用 JAR 文件方法，以确保当您的应用程序部署到产品服务器时继续正确地运行。

作为另一种解决方案，本文的其余部分介绍了一个简单插件，可以使用它，通过 zip 压缩另一个项目的内容来自动创建和维护某个项目中的 JAR 文件。当继续遵循 J2EE 规范限制时，这样做可以大大简化 J2EE 的开发过程。

J2EE 开发案例
下图 1 显示了一个典型的 J2EE 应用程序，它由 EAR、EJB、Web 和 Java 项目构成。Web 和 EJB 项目都需要使用实用程序类，而这些类当前正在 Java 项目中开发。

图 1.一个典型的 J2EE 应用程序

如上所讨论的，EJB 和 Web 项目使用这些类的最好方法是在 EAR 中创建 JAR 文件。通过修改 EJB 和 Web 项目中的清单文件，它们可以在运行时使用 JAR 文件，并可以继续完整地移植到任何 J2EE 应用程序服务器而无须任何额外步骤。

下图 2 显示了最终结果，包含一个在 EAR 项目中创建的 JAR 文件。但如何在 Java 项目的构建目录（build directory）之外创建和维护 JAR 文件呢？如果同时开发 J2EE 和 Java 项目，保持同步可能成为一个主要问题。

图 2.使用来自 EAR 的 JAR 文件

附加的插件提供了一个构建器，每当要添加、修改或删除任何类时，构建器就会自动通过 zip 压缩 Java 项目的构建目录中的内容。一旦告诉它要创建的 zip 文件位置，开发就可继续而实用程序 JAR 文件将会与 Java 项目内容保持同步。

安装 zip 创建插件
要安装 zip 文件创建插件，请遵循以下步骤：

1. 在本页底部下载 zipCreation.zip。
2. 将下载文件解压缩到 Application Developer installation/plugins 文件夹中。
3. 验证解压过程中所创建的新 Application Developer installation/plugins/com.ibm.sample.zip.creation 文件夹。

使用 zip 创建插件
要使用该插件，对每个将通过 zip 压缩进 JAR 文件的 Java 项目执行如下步骤。

1. 在 Navigator 视图中，右击 Java 项目并选择 properties。
2. 从对话框左边的列表中选择 Zip Creation。
3. 如果希望自动创建 zip 文件，则选择 Enable。这使得每次当前项目中的内容发生变化时就会创建 zip 文件。如果不希望自动创建 zip 文件，则每当要更新 zip 文件时，右击项目，然后选择项目弹出菜单中的 Update zip file(s)。
4. 确保选中 Workspace选项，单击 Browse。
5. 选择工作台中的 EAR 项目。单击 OK。
6. 在 Filename域输入新的文件名。例如， utility.jar 。
7. 现在，将完成如下图 3 所示的对话框。单击 OK。

图 3.Zip 创建属性

如果看一下 EAR 项目，您将会发现创建了一个新的 JAR 文件。当您对 Java 项目不断地进行更改时，这些更改将会反映到 JAR 文件中。

对每个需要使用 JAR 文件的 EJB 或 Web 项目而言，您需要更新清单和 Java 构建类路径以使用新的 JAR 文件。可以在使用 Edit Module Dependencies 对话框的同时执行这些步骤。请遵循如下步骤。

1. 右击 EJB 或 Web 项目，选择 Edit Module Dependencies。
2. 从如下图 4 所示的复选框列表中选择 utility.jar 。
3. 单击 OK。

图 4.Edit Module Dependencies 对话框

要禁用 zip 文件创建或者要更改设置，只需重新打开项目属性，然后更改选项。该插件可用于其它许多情况，并不局限于本案例。您还可以在工作台之外创建 zip 文件，然后添加其它源文件夹，以便在已创建的 zip 文件中包含源文件或其它资源。

结束语
通过研究 J2EE 应用程序所使用的实用程序文件的各种位置，我们发现将 JAR 文件中的实用程序类放进 WEB-INF/lib 文件夹或直接放进企业应用程序中通常是最佳的。如果实用程序类由多个模块（或即使是单个 EJB 模块）使用，那么总是使用企业应用程序。之后，我们讲述了不受支持的 zip 创建插件，它作为相同团队共同开发实用程序类和 J2EE 应用程序所存在问题的一种解决方案。

下载

	Name				Size				Download method
	zipCreation.zip				41 KB				HTTP