Bug 51580 - Severe error deploying WAR application (ExpandWar error)
Severe error deploying WAR application (ExpandWar error)
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Catalina
7.0.19
PC All
: P2 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-07-28 22:41 UTC by Cleon
Modified: 2014-12-02 04:36 UTC (History)
0 users



Attachments
Catalina log file with the error. (9.46 KB, text/plain)
2011-07-28 22:41 UTC, Cleon
Details
Minimal war to reproduce the problem (1.68 KB, application/octet-stream)
2011-08-13 20:17 UTC, Cleon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cleon 2011-07-28 22:41:57 UTC
Created attachment 27330 [details]
Catalina log file with the error.

When trying to deploy a WAR application (50MB approx) I get:

"SEVERE: Error deploying web application archive gestaoApolices.war
java.lang.NullPointerException"

Complete stacktrace is attached.

I've seen in the sources that this might be related with the correction of "Bugzilla 33636"

Let me know if the war file is needed, in case you're not able to reproduce the problem.
Comment 1 Cleon 2011-07-28 23:18:19 UTC
I've just find out that the problem was in a specific file within the WAR:

"Cliente-TextExtractRules-Açoreana.properties"

The file name has Portuguese accented char "ç".

After replace the char by "c" in that file, the deployment was done ok.
Comment 2 Mark Thomas 2011-07-29 21:25:24 UTC
Your WAR file is not valid. I suspect it was created with a zip utility rather than with jar. The default character sets are different. You need to use jar if you have file names that are use non-ASCII characters.
Comment 3 Cleon 2011-07-30 00:21:30 UTC
Actually was using the zip's Ant task to produce the war file and I didn't realized that because it's a automatically generated build.xml from Google GWT.
Comment 4 Konstantin Kolinko 2011-07-30 14:32:59 UTC
Zip uses platform default encoding to encode file names.
JAR uses UTF-8.


java.lang.NullPointerException
        at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:407)
        at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:138)

It looks as if InputStream reference in ExpandWar#expand(InputStream, File) was null. That is an earlier call to jarFile.getInputStream(jarEntry) on ExpandWar.java:135 returned null.

The Javadoc for JarFile#getInputStream(ZipEntry) does not say that it can return null. I would have expected a ZipException here.
Comment 5 Christopher Schultz 2011-08-01 18:35:58 UTC
It seems like adding a null check here would be good, since NPE in Tomcat looks like a bug in Tomcat instead of an error in the WAR file. I'm re-opening for that reason.

Please re-close INVALID if you are adamant about not having a null check.
Comment 6 Mark Thomas 2011-08-01 21:23:28 UTC
I'm not overly concerned about this. If you want to patch it, go ahead. If you don't I'll eventually close this as WONTFIX.
Comment 7 Christopher Schultz 2011-08-12 19:02:50 UTC
Cleon, can you attach a minimal WAR file that reproduces this issue? Also, if there are any environmental settings necessary, such as expandWars="false", please let me know.
Comment 8 Cleon 2011-08-13 20:17:31 UTC
Created attachment 27385 [details]
Minimal war to reproduce the problem

Here's the file. There's no special env settings, just import the file.

Regards,
   Cléon
Comment 9 Mark Thomas 2011-08-15 10:55:06 UTC
Changing back to an enhancement. There is no Tomcat bug here.
Comment 10 Christopher Schultz 2011-08-25 13:55:26 UTC
(In reply to comment #4)
> Zip uses platform default encoding to encode file names.
> JAR uses UTF-8.

I'm not so sure that's true:

$ echo $LC_CTYPE
en_US.UTF-8

$ jar tvf 51580.war 
     0 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/
   594 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/Cliente-TextExtractRules-Açoreana.properties
   570 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/Cliente-TextExtractRules-Liberty.properties

$ LC_CTYPE=en_US.ISO-8851-1 jar tvf 51580.war 
     0 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/
   594 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/Cliente-TextExtractRules-A?oreana.properties
   570 Sat Aug 13 21:06:34 EDT 2011 text_extraction_rules/Cliente-TextExtractRules-Liberty.properties

$ unzip -v 51580.war 
Archive:  51580.war
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Stored        0   0% 2011-08-13 21:06 00000000  text_extraction_rules/
     594  Stored      594   0% 2011-08-13 21:06 3271f2b8  text_extraction_rules/Cliente-TextExtractRules-A?oreana.properties
     570  Stored      570   0% 2011-08-13 21:06 a00a7a2c  text_extraction_rules/Cliente-TextExtractRules-Liberty.properties
--------          -------  ---                            -------
    1164             1164   0%                            3 files


When my file.encoding ends up being ISO-8859-1, jar acts just as stupidly as zip.
Comment 11 Christopher Schultz 2011-08-25 15:18:55 UTC
Interestingly enough, Apache Ant's "zip" and "jar" tasks both have an "encoding" attribute to control the charset used for filenames, but they have a subtle difference in their default configurations.

The <zip> task defaults to the platform's default encoding while the <jar> task defaults to UTF-8 with a *strong* warning not to change the default <jar> encoding unless you know what you're doing.

http://ant.apache.org/manual/Tasks/zip.html#encoding

So it looks like Cleon must have used <zip> instead of the much more appropriate <war> task to create his WAR file.

Still, I think it's a good idea to throw a different kind of exception. NPEs make it look like there is an actual bug in Tomcat which is certainly not the case.
Comment 12 Christopher Schultz 2011-09-20 20:33:33 UTC
Fixed in trunk and 7.0.x branch. Will be included in 7.0.22 onward.