Apache Cocoon won't start (java.util.zip.ZipException)

[David G. Douthitt]

I'll try to compress the error message suitably (but not extraordinarily). The message is:

Oct 23, 2007 4:28:48 PM org.apache.catalina.core.StandardContext start
SEVERE: Error in dependencyCheck java.util.zip.ZipException: invalid entry size (expected 2472738816 but got 48 bytes)

The cocoon.war file was installed with HP-UX 11iv3, and swverify finds no errors with the package hpuxwsXML. Tomcat works fine and the error with Cocoon happens on startup (though Tomcat succeeds).

The versions are:

hpuxwsAPACHE: B.2.0.58.00
hpuxwsTOMCAT: B.5.5.9.04
hpuxwsXML: A.2.01

I'd look into a cocoon.war file from the Apache Cocoon project, but last I heard they'd stopped creating binaries.

This version of 11iv3 contains the latest (Sept. 2007) patch bundle as well.

I tried this cocoon.war file on two different machines (clustered with a Tomcat package) with the same results in both cases. The package was brought down and then back up on the different nodes (with no failover - AUTORUN is off).

I can't find any zip or unzip utilities; presumably the Zip process is being handled by a Java program/procedure. 7zip on Windows is able to extract the *.war file, and finds no errors; HP-UX Tomcat also extracts the file just fine (at runtime).

One apparently relevant snippet from the stack trace may be this:

at org.apache.catalina.util.ExtensionValidator.getManifest(Unknown Sourc
e)
at org.apache.catalina.util.ExtensionValidator.validateApplication(Unkno
wn Source)
at org.apache.catalina.core.StandardContext.start(Unknown Source)

However, as I said, the *.war file extracts just fine. Tomcat is being started using the setup from the ServiceGuard/Tomcat Toolkit and with the cmrunpkg tomcat command.

PS: There is another David Douthitt..... but I *seriously* doubt it would be none other than myself. How do I fix that?

Thanks!

[Steven Schweda]

I may be out of my depth here, but if
cocoon.war is some kind of Zip archive, and
if it's either bigger than 2GB or has a
member which is bigger than 2GB, then many
kinds of unzip programs will have trouble,
possibly looking like this.

Until fairly recently, the Zip archive format
used only 32-bit file size values. In some
environments the sizes are interpreted as
unsigned, allowing values up to 4GB, while in
others they're interpreted as signed,
allowing values up to 2GB. The latter is, I
believe, more typical on UNIX (-like)
systems, such as HP-UX. In the Info-ZIP
Zip and UnZip programs, it comes down to
whether off_t is signed or unsigned, and the
modern standard says signed. In other
implementations, many things are possible.
(On very old VMS VAX systems, you can get an
unsigned off_t, but that won't help you
here.)

I know nothing, but I would not be amazed if
the HP-UX Java unzip code had a 2GB size
limit, while 7zip on Windows had a 4GB size
limit. In which case, you may be doomed.

> [...] the *.war file extracts just fine.

Well, try it with an UnZip program on HP-UX
and see how far you get.

[David G. Douthitt]

I suppose it would be possible that the 2G limit is causing problems, except that it should work since it is a HP-UX 11iv3 installed configuration. These are not add-on programs here.

However, the cocoon.war file is listed as 14M in size (specifically, 14776318 bytes). That does not come up against the 2G limit by a long shot - and I think (though don't know) that the filesystem (/opt) is large-file aware in any case.

[Steven Schweda · Accepted solution]

> [...] the cocoon.war file is listed as
> 14M in size (specifically, 14776318 bytes).
> That does not come up against the 2G limit
> by a long shot

As I said, "or has a member which is bigger
than 2GB", but I wouldn't bet on that from a
14MB archive. Knowing nothing about the size
of the archive or its contents until now (and
I still haven't seen anything about its
contents), it was hard to know whether that
"expected 2472738816" (one of the few data
you did supply) had anything to do with
reality or not. Blame my ignorance on weak
psychic powers, if you wish.

> - and I think (though don't know) that the
> filesystem (/opt) is large-file aware in
> any case.

A file system with large-file capabilities
does not ensure large-file capabilities in
the parts of the C run-time library being
used, as a little experimentation with
Info-ZIP Zip 2.x and UnZip 5.x can clearly
show.

> Well, try it with an UnZip program on HP-UX
> and see how far you get.

Still waiting for a report on that outcome.
(Assuming, of course, that the ".war" file
really is a normal Zip archive.) Commands
like "unzip -t", "unzip -l", and "unzip -lv"
could be informative.

[Steven Schweda]

> [...] the cocoon.war file is listed as
> 14M in size (specifically, 14776318 bytes).

If it's any comfort, around here:

dy # ls -l /opt/hpws/xmltools/cocoon/cocoon.war
-r--r--r-- 1 bin bin 14776318 Feb 10 2004 /opt/hpws/xmltools/cocoon/cocoon.war

dy # cksum /opt/hpws/xmltools/cocoon/cocoon.war
2664803458 14776318 /opt/hpws/xmltools/cocoon/cocoon.war

And UnZip loves it:

dy # unzip -t /opt/hpws/xmltools/cocoon/cocoon.war
Archive: /opt/hpws/xmltools/cocoon/cocoon.war
testing: META-INF/ OK
testing: META-INF/MANIFEST.MF OK
testing: i18n/ OK
[...]
testing: logicsheets/hello.xsl OK
testing: templates/hello-page.vm OK
No errors detected in compressed data of /opt/hpws/xmltools/cocoon/cocoon.war.

[Steven Schweda]

I see points, but it would be nice to know if
you actually learned anything useful (here or
elsewhere), and, if so, what.