Am Donnerstag, den 09.06.2011, 09:40 +0100 schrieb Jocelyn Ireson-Paine:
> On Thu, 9 Jun 2011, Felix Schumacher wrote:
>
> > Am Donnerstag, den 09.06.2011, 04:53 +0100 schrieb Jocelyn Ireson-Paine:
> >> Hi,
> >>
> >> I'm getting sporadic null-pointer exceptions from 'response.encodeUrl'.
> >> This is with Tomcat 7.0.14, the latest stable version to which I upgraded
> >> an hour ago, and Java 1.6.0_26, which again I upgraded to at the same
> >> time, under Windows XP. I also got the error under Tomcat 5.5.33, which is
> >> why I tried upgrading. I uninstalled old Tomcats and Javas before
> >> upgrading.
> >>
> >> Here's a trace of the error:
> >> java.lang.NullPointerException
> >> at
> >> org.apache.catalina.connector.Response.toAbsolute(Response.java:1594)
> >> at
> >> org.apache.catalina.connector.Response.encodeURL(Response.java:1198)
> >> at
> >> org.apache.catalina.connector.ResponseFacade.encodeUrl(ResponseFacade.java:422)
> >> at sharesim.ValueGame.encodeUrl(ValueGame.java:468)
> >> The fourth line of the trace is my code.
> >>
> >> To get some diagnostics, I encapsulated 'response.encodeUrl' in the
> >> following method, and used 'println' to print to Tomcat's log. This method
> > You can use the servlet api's log method to log inside a web
> > application, or even better use a logging-framework.
> >
> >> is the one mentioned on the fourth line of the above trace.
> >> private final static String encodeUrl( HttpServletResponse response
> >> , String url
> >> )
> >> {
> >> System.out.println( "encodeUrl" );
> >> System.out.println( "response=" + response );
> >> System.out.println( "url=" + url );
> >> String result = null;
> >> if ( response == null )
> >> result = "not on Web";
> >> else
> >> result = response.encodeUrl( url );
> >> System.out.println( "result=" + result );
> >> return result;
> >> }
> >>
> >> As mentioned above, the errors are sporadic. My redirection code gets
> >> called on my server when I submit one of my forms. But sometimes, the
> >> submit works; sometimes it doesn't. Here are two successive traces from
> >> the above method:
> >> encodeUrl
> >> response=org.apache.catalina.connector.ResponseFacade@1a5ec6c
> >> url=/ResearcherValueGame1.jsp
> >> result=/ResearcherValueGame1.jsp
> >>
> >> encodeUrl
> >> response=org.apache.catalina.connector.ResponseFacade@1a5ec6c
> >> url=/ResearcherValueGame1.jsp
> >> The first one worked; the second crashed rather than returning the encoded
> >> URL. The URL to be encoded is the same in both cases, and 'response' is
> >> evidently the same instance. I don't know how to dump 'response' in order
> >> to show relevant fields (whichever they are), but am happy to try it if
> >> someone can suggest how.
> >
> > You haven't shown us the code, which calls your encodeUrl. Most of the
> > times someone reports sporadic errors while working with responses, he
> > is saving references to the responses in a class variable.
> >
> > Could this be your problem?
> >
> Hi Felix, and thanks for the comment. What is it about saving references
> to the responses in a class variable that can cause problems? Is it to do
> with threading: for example, do different threads all see the same class
> variable, thus potentially interfering with one another? This is something
> I need to know.
Instances of servlets are used multi threaded inside the servlet
container. So every shared - instance or class wise - request/response
reference will cause trouble.
So don't do this (might
class MyServlet extends HttpServlet {
// DONOT DO THIS
private Request req;
public void doGet(HttpServletRequest req, HttpServletResponse res) {
// NEVER A GOOD IDEA
this.req = req;
...
myMethod();
}
private void myMethod() {
// OHOH
workWith(this.req);
}
}
>
> More specifically, I'd like to understand why you want to know this in
> addition to the diagnostics I included with the mail. These showed two
> calls to 'response.encodeUrl'. In both, the URLs were the same. The
> response instances were presumably also the same, since they had the same
> instance ID, ResponseFacade@1a5ec6c. In particular, neither response
> instance was null. So although one call crashed, it wasn't because of a
> nulled response, caused perhaps by losing the contents of a class
> variable. I wondered whether you suspect that that might be my problem.
Responses will get recycled and might be in an inconsistent state when
you (or the container) uses them multi threaded.
Felix
>
> Although I suppose the response instances could have been interfered with
> by code that updates some of their fields. As it happens, my code
> doesn't do that (unless I remember wrongly), but you obviously wouldn't
> know that.
>
> I'm not criticising your comment, by the way; just trying to understand
> why you asked. My code is quite long, but I can summarise the call chain
> and response assignments if we don't solve the problem before.
>
> > Felix
>
> Jocelyn
>
> >>
> >> I've found a few mentions on Google of such errors, but nothing definite
> >> about it happening in Tomcat 7. One discussion which I thought I'd seen,
> >> but can't find again, seemed to suggest that the problem occurred on
> >> version 5, possibly because of a missing 'synchronized'. I've not seen
> >> anything in recent postings to this list.
> >>
> >> I wondered whether the problem might be caused by the browser creating
> >> malformed cookies, or some such. (I'm using session-handling.) However,
> >> this seems unlikely, as the error occurs regardless of whether I use
> >> Firefox, Internet Explorer, or Google Chrome.
> >>
> >> Any ideas?
> >>
> >> Jocelyn Ireson-Paine
> >> http://www.j-paine.org
> >>
> >> Jocelyn's Cartoons:
> >> http://www.j-paine.org/blog/jocelyns_cartoons/
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
