I spent awhile analyzing why our application was having a problem. We have an
unusual case - a product that was its own web server adapted to live under
JBoss/Tomcat. Now that we're running under Tomcat I decided that some new
browser UI should use JSF, but after I was running with JSF I started having
occasional problems with exceptions.

After tracking this down I finally understood the problem. We are probably (I'll
be tracking this down next) accessing an HttpServletRequest outside of the
standard loop that the dispatcher puts it through. I will grant a priori that
this is invalid and we shouldn't be doing so. 

However, the underlying issue is that methods in the request object end up
calling MessageBytes.toString. Our particular case calls the getScheme() method.
This wouldn't be a problem, but after recycle is called, the MessageBytes object
is "null". But if you call toString(), it returns false from isNull, and that
*is* a problem. My broken app should not be able to put this underlying data
structure into an invalid state by calling a getter. 

As a result of no longer being "null" from the isNull perspective, the
dispatcher no longer sets the scheme on the new request, which breaks the next
request that uses that request object.

I'd suggest two changes:

1) recycle the request right before use to limit the extent of the threading window
2) fix the toString method to not change the object's state for the null case

For #2, something like this might suffice, and is much safer than the current code:

    public String toString() {
	if( hasStrValue ) return strValue;

	switch (type) {
	case T_CHARS:
	    hasStrValue=true;
	    strValue=charC.toString();
	    return strValue;
	case T_BYTES:
            hasStrValue=true;
	    strValue=byteC.toString();
	    return strValue;
	}
	return null;
    }