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.
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.
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.
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.
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.
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.
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.
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.
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
Changing back to an enhancement. There is no Tomcat bug here.
(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.
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.
Fixed in trunk and 7.0.x branch. Will be included in 7.0.22 onward.