问题和这里描述的完全一样：
Exception java.util.zip.ZipFile.ensureOpenOrZipException with WAS 7
根据解决方案，我将应用程序模块更改为 2.4 并解决了问题。我没有改变决议中提到的wsdl的路径。但是一旦更改了应用程序模块，就不会生成 webservices.xml 文件。我需要生成xml文件。
在我不需要更改应用程序模块的情况下，有人对此问题有任何替代解决方案吗？
问候，
【问题讨论】：
标签： java web-services websphere-7
您所指的原始问题有两个部分。一是关于ZIPException。由于该异常是在 WebSphere 代码的深层触发的，因此您不太可能在此处获得该问题的解决方案。您应该为此联系 IBM 支持。另一部分是关于内存问题。根据我使用部署在 WebSphere 上的 JAX-WS 服务（以及一般使用 WebSphere）的经验，我可以提出两个建议：
最初的问题是“在几次部署之后”出现的问题。这指向类加载器泄漏。类加载器泄漏是一种特殊类型的内存泄漏，可防止应用程序的旧类加载器在重新部署或重新启动应用程序后被垃圾收集（有关更详细的描述，请参阅here）。这可能是由应用程序或服务器运行时引起的。经验表明，WebSphere 本身有几个问题会导致此类泄漏，而 IBM 通常在解决这些问题方面效率不高。我曾经编制了一份我遇到的此类已知 WebSphere 问题的列表。它已发布here。可以看出，基本上任何或多或少复杂的 Java EE 应用程序都会受到这类问题的影响。因此，你应该做好准备，在频繁重新部署而不重新启动服务器时，它最终会耗尽内存。
注意：为 IBM 辩护，应该说其他应用服务器在这方面的表现不一定更好。
在一种特殊情况下，部署在 WebSphere 上的 JAX-WS 服务可能会意外消耗大量内存。这发生在使用自顶向下方法开发的服务（即从 WSDL 开始）但具有不引用原始 WSDL 的 @WebService 注释的服务。在这种情况下，WebSphere（非常正确）认为它们是自下而上的服务，并基于 JAX-WS/JAXB2 注释生成 WSDL 和 XML Schema 文档。这些文档保存在内存中，在某些情况下（特别是对于复杂服务）可能比原始的 WSDL 和 XML Schema 文档大得多。我曾经见过一个为此消耗 200MB 堆的应用程序。为避免这种情况，请确保在创建自上而下的 JAX-WS 服务时，将原始 WSDL 和 XML Schema 文档打包到应用程序中，并且服务实现具有正确引用这些文档的 @WebService 注释。
【讨论】：