問題はここで説明されているものとまったく同じです。
WAS7での例外java.util.zip.ZipFile.ensureOpenOrZipException
解決に続いて、アプリケーションモジュールを2.4に変更し、問題を解決しました。解決策に記載されているように、wsdlのパスを変更しませんでした。ただし、アプリケーションモジュールが変更されると、webservices.xmlファイルは生成されません。xmlファイルを生成する必要があります。
アプリケーションモジュールを変更する必要がないこの問題の代替ソリューションを持っている人はいますか？
よろしく、
あなたが参照している元の質問は2つの部分に分かれています。1つはについてZIPExceptionです。その例外はWebSphereコードの奥深くでトリガーされるため、ここでその問題の解決策が得られる可能性はほとんどありません。そのためには、IBMサポートに連絡する必要があります。他の部分はメモリの問題についてです。WebSphereにデプロイされたJAX-WSサービスの使用（および一般的なWebSphereの使用）の経験から、次の2つの推奨事項を作成できます。
元の質問によると、問題は「数回の展開後に」発生します。これは、クラスローダーのリークを引き起こします。クラスローダーリークは、アプリケーションの再デプロイまたは再起動後にアプリケーションの古いクラスローダーがガベージコレクションされるのを防ぐ特定の種類のメモリリークです（詳細については、こちらを参照してください）。これは、アプリケーションまたはサーバーのランタイムが原因である可能性があります。経験によれば、WebSphere自体にこのタイプのリークを引き起こすいくつかの問題があり、IBMは一般にこれらの問題を解決するのにあまり効率的ではありません。私はかつて、私が遭遇したこのタイプの既知のWebSphereの問題のリストを編集しました。ここに公開されています。基本的に、多少複雑なJavaEEアプリケーションがこのタイプの問題の影響を受けることがわかります。したがって、サーバーを再起動せずに頻繁に再デプロイすると、最終的にメモリが不足するという事実に備える必要があります。
注：IBMを擁護するために、他のアプリケーション・サーバーがこの領域で必ずしも優れたパフォーマンスを発揮するとは限らないことに注意してください。
WebSphereにデプロイされたJAX-WSサービスが予期せず大量のメモリーを消費する可能性がある特定のケースが1つあります。これは、トップダウンアプローチを使用して開発された（つまり、WSDLから開始する）サービスで発生しますが、@WebService元のWSDLを参照しないアノテーション。その場合、WebSphereは（非常に正しく）それらがボトムアップサービスであると信じており、JAX-WS/JAXB2アノテーションに基づいてWSDLおよびXMLスキーマ文書を生成します。これらのドキュメントはメモリに保持され、場合によっては（特に複雑なサービスの場合）、元のWSDLおよびXMLスキーマドキュメントよりも大幅に大きくなる可能性があります。そのためだけに200MBのヒープを消費していたアプリケーションを見たことがあります。これを回避するには、トップダウンのJAX-WSサービスを作成するときに、元のWSDLおよびXMLスキーマドキュメントをアプリケーションにパッケージ化し、サービス実装@WebServiceにこれらのドキュメントを正しく参照するアノテーションが含まれていることを確認してください。