tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
Date Wed, 15 Jun 2011 19:12:58 GMT
Hash: SHA1


On 6/15/2011 1:43 PM, Jocelyn Ireson-Paine wrote:
>      ResponseHolder rh = (ResponseHolder)this_session.getAttribute(
>   "response_holder" );

Here is the beginning of your errors.

By saving a reference to the response that was used for your first page
access, you have set yourself up for errors for future responses, and
not just in the JSP at hand: you could potentially cause errors in the
responses of other requests down the line that re-use the response object.

That may sound entirely insane, and it kind of is, unless you understand
that Tomcat, in order to manage the application's heap more efficiently,
re-uses both HttpServletRequest and HttpServletResponse objects. If you
store a reference to a response in your JSP (of the session), as you
have, you are saving a reference to something that is going to be
re-used countless times by other requests after "this" one.

It's best to only use request and response objects during the actual
request that is being handled.

>      out.println( "rh = " + rh + ".<BR>" );
>      if ( rh == null ) {
>        out.println( "rh is null.<BR>" );
>        rh = new ResponseHolder( response );
>        this_session.setAttribute( "response_holder", rh );
>        this_session.setAttribute( "count", 0 );
>        out.println( "<BR>count = 0.<BR>" );
>     }
>     else {
>        int count = (Integer)this_session.getAttribute( "count" );
>        out.println( "rh is not null.<BR>" );
>        this_session.setAttribute( "count", count+1 );
>        out.println( "<BR>count = " + (count+1) + ".<BR>" );
>     }

I'm unsure of why you need to store the response object at all, here.
Does it accomplish something that isn't clear from the cost you've posted?

What if you remove the ResponseHolder object entirely from your code?
Does everything still work as expected (with the added benefit of not
crashing in weird ways)? I suspect so.

>     try {
>       result = rh.response.encodeURL( "/Test1.jsp" );

Here, just use "response.encodeURL" instead of "rh.response.encodeURL".

> I store users' session data
> in instances with many fields, of which an HTTPServletResponse is one.

Can you survive without storing the HttpServletResponse?

> I
> pass these to my server-side code. This needs the HTTPServletResponse
> when doing such things as encoding URLs, which is why I include it. For
> the purposes of this test, the non-HTTPServletResponse fields aren't
> relevant, and so I've not included them in the ResponseHolder.

I would highly recommend that you pass-in the HttpServletResponse as a
parameter to whatever methods need access to it. Otherwise, you will be
tempted to store a reference to the request (or response) and things
will start to break apart.

I hope that helps,
- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message