tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Date Fri, 08 Jul 2011 19:54:29 GMT
Hash: SHA1


On 7/8/2011 8:00 AM, eurotrans-Verlag wrote:
> After compiling and running it with the Oracle Java 1.6.0_26, the 
> line number printed was the line with the "str.toLowerCase()", not 
> the "System.out.println". So I assume the same is true for the 
> compiled Tomcat, thus I supposed that only container or the logger 
> could be null).

The compiler must have gotten smarter than the last time I checked.

>> Problem solved?
> Well, I don't know what the original problem was, so I don't know if 
> it is solved. ;)
> My concern at the moment is not the original exception that occurred,
> but the NPE that suppressed that exception, because if it happens
> again, I will not able to see what was the original exception.

You could modify the source and add another dump of the original
exception (say, to stdout). That way, if it does happen again, you'll at
least see the root cause.

> As Pid said, it could have something to do with the old context which
> was still waiting for a request to finish, and as I stated in the
> other message, I could reproduce a NPE, but in 
> StandardContextValve.invoke() (there "context" was null). But NPEs 
> thrown are never good, are they?

No, it sounds like that might be a rarely-seen bug in Tomcat since it
happens only during context reload while a long-running request is in
progress. If you can build a simple test case, attach it to a new BZ
entry and we'll see about getting it fixed.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message