This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE 7.1 RC1 (Build 201111171527) VM: Java HotSpot(TM) Client VM, 21.1-b02, Java(TM) SE Runtime Environment, 1.7.0_01-b08 OS: Windows 7 User Comments: javydreamercsw: Deploying a web applciation. qpolarbear: Checked out a new branch in git (outside of the IDE). Caused NetBeans to rescan. kahatlen: Right-clicked a project and chose "Clean and Build" from the pop-up menu. Stacktrace: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(ZipFile.java:0) at java.util.zip.ZipFile.<init>(ZipFile.java:214) at java.util.zip.ZipFile.<init>(ZipFile.java:144) at java.util.jar.JarFile.<init>(JarFile.java:152) at java.util.jar.JarFile.<init>(JarFile.java:89) at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
Created attachment 113386 [details] stacktrace
Created attachment 113902 [details] stacktrace
Created attachment 113973 [details] Log
The error is preventing me from debugging a Web application. See attachment.
Hi, which server (and version) are you deploying to? If you are using GlassFish 3.1.1, then I suspect you may be running into a jar locking problem on the GlassFish side, see: https://netbeans.org/bugzilla/show_bug.cgi?id=202419 http://java.net/jira/browse/GLASSFISH-17339 The GlassFish bug report says that it was fixed in GF 3.1.2 promoted build 13, so can you please check if this problem disappears if you use this build as the target server? http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/ Thanks.
I was using Tomcat 7.0.23. I was able to make it work after wiping out my user dir and restarting NetBeans a couple of times.
It's possible that there may be a locking problem in Tomcat as well.
This doesn't look like the windows file locking problem. there are non-windows instances of this exception.
Created attachment 114353 [details] stacktrace loading project from pendrive...
Now that you mention it I want to add that I work from an External hard drive. Both NetBeans and my projects are in an external hard drive.
Can you please try if this is still happening in the latest build of NetBeans 7.2? http://bits.netbeans.org/download/trunk/nightly/ The JSP parser was recently updated to the version from GlassFish 3.1.2, so this may help. Also, the weird thing is that there are no reports of this problem with JDK 6, so there is a possibility that this is a regression on the JDK side between 6 and 7. Can anyone reproduce with JDK 6? It may also be a good idea to try with the recently released JDK 7u4, which contains a lot of bugfixes.
By updating to GF 3.1.2 JSP parser exactly the call where the exception starts was removed (although some reflection still stays). So I would propose to close this one as fixed or worksforme and if that problem still exists, an issue will be raised with the new stacktrace. So closing as workforme since web-main #646171d74911 (you can see that the "cache.getLocation("");" was commented out and another way used for refreshing tlds caches).
It looks that the problem stays also for the newest jdk and nb sources (which was probably expected), reopenning.
I am thinking how this could be happening. Any ideas? Some wild guesses: - Both server and the IDE (JSP parser included in the IDE) are trying to access the same jar file at the same time (in theory, they should open the file for just a short while and close it as soon as they're done reading from it, but they could clash at some point). - Someone is not closing the jar file correctly (maybe due to an exception and missing finally block where the close method would be called?) I am thinking if it would help if we were logging the exact location of the failing jar file, what do you think?
It doesn't look to me that there is any problem with the jspparser call. Anyway I didn't figured out yet why the exception is not catched as InvocationTargetException. The situation how it looks like to me: The JSP parser was properly called and it refreshes and scans all jars which it needs. By doing that some of JAR files can't be opened and throws ZipException. But this exception should be wrapped into InvocationTargetException and logged with Level.INFO level what probably didn't happen since another exception report come.
I got it (at least the cause). This exception is logged directly by the TldScanner with the WARNING level, so these exceptions are catched by our exception reporter. So there is just needed to find a way how to disable its own logger and use our one.
Ok, these TldScanner warnings are filtered out and logged with INFO level by our logger now. Fixed in web-main #f896897654aa.
*** Bug 204781 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden', will be available in build *201205100400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f896897654aa User: Martin Fousek <marfous@netbeans.org> Log: #205387 - [71cat] java.util.zip.ZipException: error in opening zip file