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