title: How to correct the error 'java.util.zip.ZipException: error in opening zip file' invoking web service on WAS with Portal
body: <p>I have developed a web service for Portal 7.0 and deployed the application into an environment. The installation and start up of the application is fine, however, when the web service is invoked, the following error appears in the SystemOut.log a few hundred times. The server then starts reporting other errors about 'Too many open files' until the application is stopped or the services restarted.</p>
  
  <pre><code>[7/29/14 8:45:56:647 EST] 00000057 WSClassFinder E   WSWS7058E: A JAXBContext could not be created correctly because of the following error: java.util.zip.ZipException: error in opening zip file
  [7/29/14 8:45:56:647 EST] 00000057 WSClassFinder E   WSWS7058E: A JAXBContext could not be created correctly because of the following error: java.util.zip.ZipException: error in opening zip file
  </code></pre>
  
  <p>Strange thing is we have a development and production environment that are basically identical (Same Linux OS version + WAS and Portal 7.0.0.23). Initially the web service worked fine in dev, but an attempt to use it in production failed (Not a good look). After rebooting dev, the problem started to occur there as well (at least it is now consistent).</p>
  
  <p>I also tried to build the most basic of basic web service applications (it just returns a single static string) and even that failed with exactly the same result when invoked. I have a separate development environment where I do most of my work which is separate to the one above, but with the same app versions. This one has always worked fine. This suggests it is a configuration or server issue.</p>
  
  <p>I have used tracing on the com.ibm.ws.classloader and java.util.zip without any very useful information. Class loader didn't seem to clearly indicate the root of the problem and java.util.zip didn't report anything in the trace.</p>
  
  <p>Unfortunately I'm stuck with where to look for options to correct this. It could be an OS file permissions problem, but its not clear where this may be. There is an upgrade of this environment planned, but because it was previously working on this build version (on the dev server) I'd really like to get to the root cause before pursuing the upgrade.</p>
  
  <p>Any suggestions or pointers would be most appreciated.</p>