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.

Bug 31573 - Jar file keeps throwing exceptions - invalid LOC header (bad signature)
Summary: Jar file keeps throwing exceptions - invalid LOC header (bad signature)
Status: VERIFIED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Tomcat (show other bugs)
Version: 3.x
Hardware: All Linux
: P2 blocker with 2 votes (vote)
Assignee: Petr Jiricka
URL:
Keywords: RANDOM
: 31938 32108 37684 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-02-28 14:13 UTC by willow
Modified: 2005-12-09 14:23 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
the ide.log (27.96 KB, text/plain)
2003-02-28 14:16 UTC, willow
Details

Note You need to log in before you can comment on or make changes to this bug.
Description willow 2003-02-28 14:13:39 UTC
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.
Comment 1 willow 2003-02-28 14:16:32 UTC
Created attachment 9215 [details]
the ide.log
Comment 2 willow 2003-02-28 14:20:58 UTC
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
Comment 3 Jesse Glick 2003-02-28 15:46:31 UTC
Guessing this is handled by tomcatint module, maybe web? Don't know.
Comment 4 _ rkubacki 2003-02-28 17:38:50 UTC
Erwin: Is the mentioned jar really corrupted or not?
Comment 5 willow 2003-02-28 18:15:10 UTC
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
Comment 6 Milan Kuchtiak 2003-03-03 14:12:32 UTC
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.
Comment 7 willow 2003-03-05 09:17:06 UTC
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.
Comment 8 psuk 2003-03-12 14:16:37 UTC
*** Issue 31938 has been marked as a duplicate of this issue. ***
Comment 9 psuk 2003-03-12 14:19:15 UTC
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)
...
Comment 10 dotsphinx 2003-04-02 15:24:08 UTC
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.
Comment 11 willow 2003-04-02 16:17:36 UTC
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. :-)
Comment 12 psuk 2003-04-04 07:34:52 UTC
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)
Comment 13 psuk 2003-04-04 07:36:53 UTC
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.
Comment 14 psuk 2003-04-04 07:40:31 UTC
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
Comment 15 psuk 2003-04-04 07:50:44 UTC
*** Issue 32108 has been marked as a duplicate of this issue. ***
Comment 16 Petr Jiricka 2003-04-04 17:24:34 UTC
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.
Comment 17 Petr Jiricka 2003-04-07 19:32:57 UTC
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
Comment 18 willow 2003-04-07 21:05:41 UTC
Thanks,

I hope Sun comes up with some solution.
Do we have a workaround that makes sense in the meantime?
Comment 19 Petr Jiricka 2003-04-08 08:59:44 UTC
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.

Comment 20 Petr Jiricka 2003-04-10 09:05:27 UTC
The JDK bug now has an external URL:

http://developer.java.sun.com/developer/bugParade/bugs/4843
994.html
Comment 21 Petr Jiricka 2003-04-15 09:26:07 UTC
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.
Comment 22 willow 2003-04-16 07:27:10 UTC
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?
Comment 23 Patrick Keegan 2003-04-28 20:18:36 UTC
adding relnote keyword
Comment 24 Petr Jiricka 2003-04-29 10:17:19 UTC
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.
Comment 25 inertia 2003-07-10 23:15:46 UTC
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.
Comment 26 Petr Jiricka 2003-09-10 08:04:44 UTC
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/
Comment 27 psuk 2004-01-09 23:01:46 UTC
*** Issue 37684 has been marked as a duplicate of this issue. ***
Comment 28 Petr Jiricka 2004-01-27 14:35:02 UTC
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.
Comment 29 Patrick Keegan 2004-03-03 22:37:28 UTC
will not release note for NB 3.6; still valid for arrow, etc.?
Comment 30 Petr Jiricka 2004-03-04 19:00:32 UTC
Correct.
Comment 31 Jaroslav Pospisil 2005-12-09 10:25:23 UTC
VERIFIED
Comment 32 Patrick Keegan 2005-12-09 14:23:12 UTC
removing RELNOTE keyword