0

问题与此处描述的完全相同：

WAS 7 的异常 java.util.zip.ZipFile.ensureOpenOrZipException

解决后，我将应用程序模块更改为 2.4 并解决了问题。我没有改变决议中提到的wsdl的路径。但是一旦更改了应用程序模块，就不会生成 webservices.xml 文件。我需要生成 xml 文件。

在我不需要更改应用程序模块的情况下，有人对此问题有任何替代解决方案吗？

问候，

4

1 回答 1

1

您所指的原始问题有两个部分。一是关于ZIPException. 由于该异常是在 WebSphere 代码的深层触发的，因此您不太可能在此处获得该问题的解决方案。您应该为此联系 IBM 支持。另一部分是关于内存问题。根据我使用部署在 WebSphere 上的 JAX-WS 服务（以及一般使用 WebSphere）的经验，我可以提出两个建议：

  1. 最初的问题说问题发生在“几次部署之后”。这指向类加载器泄漏。类加载器泄漏是一种特殊类型的内存泄漏，可防止应用程序的旧类加载器在重新部署或重新启动应用程序后被垃圾收集（有关更详细的描述，请参见此处）。这可能是由应用程序或服务器运行时引起的。经验表明，WebSphere 本身有几个问题会导致此类泄漏，而 IBM 通常在解决这些问题方面效率不高。我曾经编制了一份我遇到的此类已知 WebSphere 问题的列表。它在这里发布. 可以看出，基本上任何或多或少复杂的 Java EE 应用程序都会受到这类问题的影响。因此，您应该做好准备，当频繁重新部署而不重新启动服务器时，它最终会耗尽内存。

    注意：为 IBM 辩护，应该说其他应用服务器不一定在这方面表现更好。

  2. 在一种特殊情况下，部署在 WebSphere 上的 JAX-WS 服务可能会消耗出乎意料的大量内存。这发生在使用自顶向下方法（即从 WSDL 开始）开发的服务，但@WebService不引用原始 WSDL 的注释。在这种情况下，WebSphere（完全正确）认为它们是自下而上的服务，并基于 JAX-WS/JAXB2 注释生成 WSDL 和 XML Schema 文档。这些文档保存在内存中，并且在某些情况下（尤其是对于复杂服务）可能比原始的 WSDL 和 XML Schema 文档大得多。我曾经见过一个为此消耗 200MB 堆的应用程序。为避免这种情况，请确保在创建自上而下的 JAX-WS 服务时，将原始 WSDL 和 XML Schema 文档打包到应用程序中，并且服务实现具有@WebService正确引用这些文档的注释。

于 2012-09-19T17:41:33.000 回答