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.
Almost every time I run execute (Force reload) on an jsp-file an error occurs complaining about " invalid LOC header (bad signature)". I use one directory which is packaged into a jar file.
Created attachment 9215 [details] the ide.log
I could really use some help on this problem. I just installed Netbeans3.4.1 It occured all the time in Forte4J so I installed Netbeans, hoping it would disappear. :-( Can it have something to do with the JAR-packager? And somebody please place this report in the right place, because I don't know what I had to choose while filing this report. Sorry for any inconvenience! Regards, Erwin
Guessing this is handled by tomcatint module, maybe web? Don't know.
Erwin: Is the mentioned jar really corrupted or not?
No The jar isn't corrupted AFAIK. I can unpack it and such. I deleted it and recreated it many times with JAR-packager. Could I do something stupid? I have a directory with some files named dsitehelpers. I have a JAR-recipe that creates a file named dsitehelpers.jar in the WEB-INF/lib directory But I get errors when I use the IDE normally, especially when I try to rightclick my index.jsp to launch Tomcat. These errors always complains about JENTRY and invalid LOC and such, anf they alway mentions the path of my dsitehelpers.jar. I am at a loss. :-/ If you need more information, let me know. Thanks
Do the packeges in your jar file correspond with the (import)packege names in your index.jsp file ? In order to reproduce that bug succesfully - it would be really helpful to create the test case and send it as an attachement. I means - create the small module with your index.jsp file and dsitehelpers.jar file and pack it as a war file. Then send it as an attachement. Of course remove your private files from the test case. Thank You.
Hi, Sorry for the late response... I am doing 13 hours a day now :-( It is quite a big job to isolate the problem because my app is quite big and I am not experienced enough to quickly isolate the jar problem right now. I understand it will make debugging things a lot easier if I can. But I have found one more thing that can maybe help: I run Netbeans 3.4.1 from a shell, and I found these messages in the shell: Controller:: couldn't read the file Controller:: couldn't read the file Controller:: couldn't read the file etc. Regards, Erwin PS: When I have some time I will surely try to isolate the JAR-problem.
*** Issue 31938 has been marked as a duplicate of this issue. ***
From Issue 31938 (leomekenkamp@netbeans.org): Exceptions occur when a cvs based jar is replaced. As 'refresh' in a cvs based checkout dir is impossible (please add this, it would not only be a fast workaround for the problem described here) the workaround is to unmount and then remount the web-app. steps to reproduce: - create a web application in a cvs server - include a jar in WEB-INF/lib - do a fresh cvs checkout (in netbeans) - replace (in a shell) the aforementioned jar with a newer version - edit a jsp (in netbeans) - the following exception gets thrown at the time one would expect the command completion to kick in: Annotation: Exception occurred in Request Processor java.lang.InternalError: jzentry == 0, jzfile = 135494136, total = 357, name = /home/leo/work/workshop/workshop/web/WEB-INF/lib/ozone-1.2.x-dev.jar, i = 69, message = invalid LOC header (bad signature) at java.util.zip.ZipFile$2.nextElement(ZipFile.java:309) at java.util.jar.JarFile$1.nextElement(JarFile.java:201) at org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(TldLocationsCache.java:237) ...
I really hope to see this bug targetted at milestone 3.5, instead of 4.0. It makes my daily work with Netbeans a real struggle.
I found out a way to reproduce the problem, not always, but quite often: 1) Make sure your webapp uses a certain jar-file. 2) Mount the jarfile in the filesystem 3) Use a jar-recipe to produce the jar file. Make the target web-apps/lib/thejarfile.jar 4) Run internal Tomcat and leave it running. 5) Change a class inside this jar-file and recompile the jar-recipe. 6) restart Tomcat (force reload) on some index.jsp eg. This creates most of the time the error for me. It often re-appears three times, and then just restarts Tomcat like nothing happened. :-)
Merging issue 32108 into this one (because it's the older one) to track the progress in one thread. Reporter: rshearin@netbeans.org (rshearin) 2003-03-18 14:32 PST When working with JSPs, I sometimes get the following error message or similar error message when editing and especially when executing a jsp. This also happened when I was using Sun ONE Studio, although it has happened less often in NetBeans so far. (I tried to use NetBeans because I was getting the error message so often in Sun ONE Studio.) This happens with any of my jsps, not just specific ones. It is not reproducible on demand but rather just happens periodically on one PC. Have never experienced the problem on another PC but have reinstalled both NetBeans and Sun ONE Studio to no avail. Both PCs have the same OS build. I can click through the error messages and edit or execute the files but it has become quite an annoying problem. Annotation: Exception occurred in Request Processor java.lang.InternalError: jzentry == 0, jzfile = 390708000, total = 55, name = C:\TogetherSoft\Together6.0.1 \myprojects\Reagents\Reagent_Management\src\jsp\WEB- INF\lib\reagentsPC.jar, i = 21, message = invalid LOC header (bad signature) at java.util.zip.ZipFile$2.nextElement (ZipFile.java:309) at java.util.jar.JarFile$1.nextElement (JarFile.java:201) at org.apache.jasper.compiler.TldLocationsCache.tldConfigJar (TldLocationsCache.java:237) at org.apache.jasper.compiler.TldLocationsCache.processJars (TldLocationsCache.java:210) at org.apache.jasper.compiler.TldLocationsCache.<init> (TldLocationsCache.java:139) at org.netbeans.modules.web.jspparser.WMDataCache.getTldLocati onsCache(WMDataCache.java:96) at org.netbeans.modules.web.jspparser.OptionsImpl.<init> (OptionsImpl.java:55) at org.netbeans.modules.web.jspparser.OptionsImpl.<init> (OptionsImpl.java:48) at org.netbeans.modules.web.jspparser.JspParserImpl.parsePage (JspParserImpl.java:103) at org.netbeans.modules.web.core.jsploader.TagLibParseSupport$ ParsingRunnable.run(TagLibParseSupport.java:121) at org.openide.util.Task.run(Task.java:136) [catch] at org.openide.util.RequestProcessor$Processor.run (RequestProcessor.java:599)
Reporter: rshearin@netbeans.org (rshearin) 2003-03-19 07:30 PST jar file is not corrupted when opening using Winzip. I also deleted the jar and recreated it with a new name and received the error message on the new jar. Application also ran successfully on standalone Tomcat.
Reporter: rshearin@netbeans.org (rshearin) 2003-03-20 06:57 PST Attachement: ide.log showing Invalid LOC bad signature error is on: http://www.netbeans.org/issues/showattachment.cgi?attach_id=9472&file=P:\ide.log
*** Issue 32108 has been marked as a duplicate of this issue. ***
So far I have found out the following: I can sometimes reproduce the bug. I don't know how to reproduce it consistently. I can reproduce the bug even without starting an external Tomcat. I have created a simple test program (will attach it later), whose is extracted from the TldLocationsCache class in Jasper. It simulates what the internal JSP parser (which is what causes the exception) does, i.e. going through the jar files in WEB-INF/lib, opening them using a JarURLConnection, and then iterating over all entries. Using this program, I can use the following steps to reproduce the bug: 1. Create a jar file using the jar recipe 2. Run the above test program (which iterates over the entries) in the same VM. 3. Modify the jar content somehow (add files, modify files) and repackage in the IDE. 4. Repeat steps 2 and 3 several times. The bug does not appear if I do one of the following: - execute the test program in another VM - call setUseCaches(false) on the JarURLConnection that reads the jar file. These facts indicate that the root cause of the problem is in the JDK's caching mechanism for jar files in JarURLConnection. Also, I found out that there is a strange "feature" of the JDK: If I open the JarURLConnection, (in the caching mode), get the jar file from it, and then close the jar file, then any subsequent instance of JarURLConnection in this VM, which also uses the caches, will not be able to read the file at all ! This I think should be filed as a JDK bug.
Filed a JDK bug: 4843994. This is not yet visible at java.sun.com, only internally at Sun: http://dtsw.eng/cgi-bin/bugtraq_showbug?bugid=4843994
Thanks, I hope Sun comes up with some solution. Do we have a workaround that makes sense in the meantime?
All workarounds I can think of are very inconvenient and difficult. One possibility is to remove the JSP Parser module from the modules/eager directory of the IDE. However, this will disable code completion for custom JSP tags, and I am not sure it will not cause other problems. Another way to get around this would be to do somehow call JarURLConnection.setDefaultUseCaches(false) inside the IDE VM. This can be done by writing a Java main class and running it using the "Internal" execution. Again, I am not sure this will help.
The JDK bug now has an external URL: http://developer.java.sun.com/developer/bugParade/bugs/4843 994.html
Raising priority to P2 and requesting a waiver for the S1S 5 release. Based on the discussions with the JDK team, it is nearly impossible to fix the JDK bug for JDK 1.4.2 - will be addressed for JDK 1.5.
The following comment raises some questions for me: <From Sun: http://developer.java.sun.com/developer/bugParade/bugs/4843994.html> --------------------------------------- Duplicate of 4425695. Modifying a jar file on the fly is not supported any more than changing a shared library or a class file on the fly. The only reason way to replace a jar file is to guarantee that the classloader (and all of its loaded classes and all objects of those) are no longer in use and suitable for garbage collection. --------------------------------------- Does this mean that every jar-file will be cached in the running JVM for ever or restart? It isn't completely clear to what goes wrong in Netbeans. (I am a newbie to this matter, so it is very well possible I don't make sense, or say things everybody takes for granted already.) As far as I know the error also occurs when I DON'T touch a jar-file. Is Netbeans changing jar-files I don't know about? Is it possible we configure Netbeans and Tomcat it always uses: setUseCaches(false), instead of setUseCaches(true) ?? If so: how? Can somebody please explain this matter a bit more?
adding relnote keyword
The easiest workaround is to develop Java classes inside WEB-INF/classes instead of putting them into a jar file. If this is not possible or desirable, restarting the IDE will help.
I'm also seeing this issue on Mac OS X, NetBeans 3.5, JDK 1.4.1. But I'm building the jar and copying with ant, not a jarRecipe. In my case, I can use the workaround and copy the classes instead of packaging them as jars. Good to know.
To answer Erwin's question: Erwin notes that it looks like the JDK bug will not be fixed any time soon, as it's not considered a bug. So the fix could be to change in Tomcat code that calls the flawed JDK code. This is exactly what I am pursuing with the Tomcat team, see the following bug against Tomcat: http://issues.apache.org/bugzilla/show_bug.cgi?id=19219 The Tomcat team did a good job on this and it looks like the issue is fixed in the Tomcat 5 code base. So this bug should be fix when we integrate with the Tomcat 5 server. A preliminary version of Tomcat 5 integration can be found in the prj40_prototype branch, see also http://projects.netbeans.org/
*** Issue 37684 has been marked as a duplicate of this issue. ***
I believe this is fixed by the fix for issue 20384. See that issue for more information. This issue is primarily caused by the fact that JarURLConnection is used in cached mode to read data from jar files that may change over time. Such scenario is (believed to be) eliminated by the fix for issue 20384. Now we use other mechanisms to read from jar files.
will not release note for NB 3.6; still valid for arrow, etc.?
Correct.
VERIFIED
removing RELNOTE keyword