You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tomcat.apache.org by Dharamshila Khandelwal <dh...@gmail.com> on 2011/06/08 19:47:24 UTC

War file deployment deletes configuration descriptor in Tomcat 6

Hi,

Every time I deploy war file in webapps, it deletes the configuration
descriptor which is present at $CATALINA_BASE/conf/[enginename]/[hostname]
directory.
Tomcat auto deploys war file in my Tomcat 6 configuration.

How should I stop this problem?

Any idea?

Thanks,
DS.

Re: War file deployment deletes configuration descriptor in Tomcat 6

Posted by Konstantin Kolinko <kn...@gmail.com>.

2011/6/8 Dharamshila Khandelwal <dh...@gmail.com>:
> Every time I deploy war file in webapps, it deletes the configuration
> descriptor which is present at $CATALINA_BASE/conf/[enginename]/[hostname]
> directory.
> Tomcat auto deploys war file in my Tomcat 6 configuration.

1. What _exactly_ version of Tomcat 6.0.x ?

2. The behaviour regarding your issue is sometimes misunderstood.

Use the latest version of Tomcat and read the docs carefully.

http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic_Application_Deployment

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: Martin Gainty [mailto:mgainty@hotmail.com] 
> Subject: RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

> place servletapi-2.3.jar in $CATALINA_HOME/bin

Absolute rubbish.  Never, never do that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Mark Thomas <ma...@apache.org>.

On 09/06/2011 19:28, Martin Gainty wrote:
> 
> place servletapi-2.3.jar in $CATALINA_HOME/bin

Monumentally bad advice. An unbelieveably stupid idea. You should *not*
do this.

Mark

> 
> $CATALINA_HOME/bin/servletapi>javap ./javax/servlet/http/HttpServletResponse | grep encodeURL
>     public abstract java.lang.String encodeURL(java.lang.String);
> 
> Martin Gainty 
> ______________________________________________ 
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>  
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> 
> 
> 
> 
> Date: Thu, 9 Jun 2011 09:06:52 +0100
> From: popx@j-paine.org
> To: users@tomcat.apache.org; users@tomcat.apache.org
> Subject: Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
> 
> On Thu, 9 Jun 2011, André Warnier wrote:
>  
>> ...
>>
>> By the way :
>>
>> (Interface HttpServletResponse, Javaee 5)
>> encodeUrl
>> String encodeUrl(String url)
>>    Deprecated. As of version 2.1, use encodeURL(String url) instead
>>
>> Maybe it's worth replacing encodeUrl by encodeURL, and see if the problem 
>> still happens.
>>
> Thanks for the suggestion, André. I've just tried that, and the problem 
> still happens.
>  
> Jocelyn
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org 		 	   		  




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Martin Gainty <mg...@hotmail.com>.

place servletapi-2.3.jar in $CATALINA_HOME/bin

$CATALINA_HOME/bin/servletapi>javap ./javax/servlet/http/HttpServletResponse | grep encodeURL
    public abstract java.lang.String encodeURL(java.lang.String);

Martin Gainty 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

Date: Thu, 9 Jun 2011 09:06:52 +0100
From: popx@j-paine.org
To: users@tomcat.apache.org; users@tomcat.apache.org
Subject: Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

On Thu, 9 Jun 2011, André Warnier wrote:

> ...
>
> By the way :
>
> (Interface HttpServletResponse, Javaee 5)
> encodeUrl
> String encodeUrl(String url)
>    Deprecated. As of version 2.1, use encodeURL(String url) instead
>
> Maybe it's worth replacing encodeUrl by encodeURL, and see if the problem 
> still happens.
>
Thanks for the suggestion, André. I've just tried that, and the problem 
still happens.

Jocelyn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

On Thu, 9 Jun 2011, André Warnier wrote:

> ...
>
> By the way :
>
> (Interface HttpServletResponse, Javaee 5)
> encodeUrl
> String encodeUrl(String url)
>    Deprecated. As of version 2.1, use encodeURL(String url) instead
>
> Maybe it's worth replacing encodeUrl by encodeURL, and see if the problem 
> still happens.
>
Thanks for the suggestion, André. I've just tried that, and the problem 
still happens.

Jocelyn

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Thomas Freitag <th...@freit.ag>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi André,

On 09.06.11 um 09:07, André Warnier wrote:
>> It does. The redirect URL set to the client can be logged with %{Location}o.

> I don't think we are talking about a redirect response sent to the client here.
> That would definitely /not/ work without a scheme.

You're right.

Regards,
- -- 
Thomas Freitag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk3wg+UACgkQGE5pHr3PKuXyDQCeO9d1x8ScRhVjpbWX+zJ7MVAh
b2EAnjv1dRtrD2GCjaiWL6pXn4QB0PSb
=K0td
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by André Warnier <aw...@ice-sa.com>.

Thomas Freitag wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Chuck,
> 
> On 06/09/2011 07:52 AM, Caldarale, Charles R wrote:
>> Can you display the original request URL, or perhaps enable the AccessLogValve?  (I'm not sure if that captures forwards, however.)
> 
> It does. The redirect URL set to the client can be logged with %{Location}o.
> 
I don't think we are talking about a redirect response sent to the client here.
That would definitely /not/ work without a scheme.

I think what Chuck meant, is that the /current/ request could be the result of a previous 
internal forward without a scheme.


By the way :

(Interface HttpServletResponse, Javaee 5)

encodeUrl

String encodeUrl(String url)

     Deprecated. As of version 2.1, use encodeURL(String url) instead


Maybe it's worth replacing encodeUrl by encodeURL, and see if the problem still happens.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Thomas Freitag <th...@freit.ag>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chuck,

On 06/09/2011 07:52 AM, Caldarale, Charles R wrote:
> Can you display the original request URL, or perhaps enable the AccessLogValve?  (I'm not sure if that captures forwards, however.)

It does. The redirect URL set to the client can be logged with %{Location}o.

Regards,
- -- 
Thomas Freitag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk3wZy8ACgkQGE5pHr3PKuVDfQCfVV8nB4w6hB0LTD+D7jh9I47B
kzEAoIEe01ttRrFab0MEuE13U7nkBy9u
=dz8u
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

On Thu, 9 Jun 2011, Caldarale, Charles R wrote:

>> From: Jocelyn Ireson-Paine [mailto:popx@j-paine.org] Subject: 
>> Null-pointer exception from response.encodeUrl under Windows Tomcat 7
>
>> I'm getting sporadic null-pointer exceptions from
>> 'response.encodeUrl'.
>
> First off, let me say that it's an unexpected pleasure to read such a 
> complete (and literate) problem description; this is a model of what 
> we'd like to see in all enquiries.
>
Thanks for the compliment, Chuck. It's nice of you to say it publicly. 
There's an essay that I read whenever I want to remind myself how to ask 
for help, and I'll mention it here in case others find it useful. Some 
will already know it: "How To Ask Questions The Smart Way", by Eric 
Raymond and Rick Moen, http://www.catb.org/~esr/faqs/smart-questions.html 
.

> ...
>
> - Chuck
>
Jocelyn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Pid <pi...@pidster.com>.

On 09/06/2011 06:52, Caldarale, Charles R wrote:
>> From: Jocelyn Ireson-Paine [mailto:popx@j-paine.org] 
>> Subject: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
> 
>> I'm getting sporadic null-pointer exceptions from 
>> 'response.encodeUrl'. 
> 
> First off, let me say that it's an unexpected pleasure to read such a complete (and literate) problem description; this is a model of what we'd like to see in all enquiries.

Shame it was a thread-hijack (from 'war file deployment...').

Please start a new email, rather than replying to an existing on in future.


p

RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: Jocelyn Ireson-Paine [mailto:popx@j-paine.org] 
> Subject: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

> I'm getting sporadic null-pointer exceptions from 
> 'response.encodeUrl'. 

First off, let me say that it's an unexpected pleasure to read such a complete (and literate) problem description; this is a model of what we'd like to see in all enquiries.

Now to the problem at hand: from browsing through the code, it appears the exception can occur if the original request had no scheme (e.g., http, https) associated with it.  I would hazard a guess that might come from an ill-constructed forward somewhere inside the webapp, since I don't think a schemeless request could come in from the outside.

Can you display the original request URL, or perhaps enable the AccessLogValve?  (I'm not sure if that captures forwards, however.)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Felix Schumacher <fe...@internetallee.de>.

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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

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.

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.

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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Felix Schumacher <fe...@internetallee.de>.

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?

Felix
> 
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Calum,

On 6/21/2011 4:26 AM, Calum wrote:
> On 20 June 2011 17:02, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> That depends on what Service.logHit does. If it only uses the
>> HttpServletRequest object during the method's lifetime, then everything
>> is fine. If it retains a reference to the request object, you will
>> probably end up with a problem.
> 
> Oh, just gets the remoteAddr, requestURI, user-agent etc, and logs it
> to a DB, for example.

No problem. You are not retaining a reference to the request object in
that case.

>> Tomcat re-uses the same request and response objects for a long time,
>> and so multiple request processor threads will see the same object over
>> the life of the server. If any of that code retains a reference to the
>> request, by the time the object is re-referenced by the same code for
>> whatever reason, the object will have "moved on" and will almost
>> certainly be invalid (from the perspective of the code that cached it)
>> and might /actually/ be invalid (because it is between requests and
>> Tomcat has actively invalidated it).
> 
> I assume that Tomcat won't reuse a request/response until activity on
> it has ended though?

Of course: during the transaction, the request and response objects
maintain sanity.

> Does it keep a pool of them?

Maybe. By default, a pool is used, but you can disable that if you are
having problems and can afford a bit of performance degradation.
Honestly, disabling that pooling should only be used when a fix is
needed immediately in production and should only be used temporarily
until your webapp is fixed.

> Thanks for your help in clarifying this for me, by the way.

No problem.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ArbkACgkQ9CaO5/Lv0PBKBACdEZc+UXO/YMbZvJaeD276vySp
pJYAoLMwetgFC0HjKg/mWlC6WWKV+O6S
=lpby
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Calum <ca...@gmail.com>.

On 20 June 2011 17:02, Christopher Schultz <ch...@christopherschultz.net> wrote:
> That depends on what Service.logHit does. If it only uses the
> HttpServletRequest object during the method's lifetime, then everything
> is fine. If it retains a reference to the request object, you will
> probably end up with a problem.

Oh, just gets the remoteAddr, requestURI, user-agent etc, and logs it
to a DB, for example.

> Tomcat re-uses the same request and response objects for a long time,
> and so multiple request processor threads will see the same object over
> the life of the server. If any of that code retains a reference to the
> request, by the time the object is re-referenced by the same code for
> whatever reason, the object will have "moved on" and will almost
> certainly be invalid (from the perspective of the code that cached it)
> and might /actually/ be invalid (because it is between requests and
> Tomcat has actively invalidated it).

I assume that Tomcat won't reuse a request/response until activity on
it has ended though?
Does it keep a pool of them?

Thanks for your help in clarifying this for me, by the way.

Calum

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Calum,

On 6/20/2011 6:12 AM, Calum wrote:
> On 15 June 2011 18:54, Konstantin Kolinko <kn...@gmail.com> wrote:
>> The request and response objects must never be accessed outside the
>> request processing cycle.  The objects are recycled and cleared or
>> reused for subsequent request and responses, and are not guaranteed to
>> be thread-safe.  The consequences can be severe.
> 
> I was interested by this.
> So:
> 
>     private Service service;
> 
>     @Override
>     public void init() throws ServletException {
>         super.init();
>         service = (Service)
> WebApplicationContextUtils.getWebApplicationContext(getServletContext()).getBean("service");
>     }
> 
>     protected void processRequest(HttpServletRequest request,
> HttpServletResponse response)
>             throws ServletException, IOException {
>     service.logHit(request);
>     ....
>     }
> 
> 
> is a bad thing?

That depends on what Service.logHit does. If it only uses the
HttpServletRequest object during the method's lifetime, then everything
is fine. If it retains a reference to the request object, you will
probably end up with a problem.

> Could you explain why?

Tomcat re-uses the same request and response objects for a long time,
and so multiple request processor threads will see the same object over
the life of the server. If any of that code retains a reference to the
request, by the time the object is re-referenced by the same code for
whatever reason, the object will have "moved on" and will almost
certainly be invalid (from the perspective of the code that cached it)
and might /actually/ be invalid (because it is between requests and
Tomcat has actively invalidated it).

> I would assume that a new request object is created each time, and
> that while something has a reference to it, it will be fine, and when
> logHit has finished with it, it will be eligible for garbage
> collection.

Nope: see Konstantin's and me comments above.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk3/bwUACgkQ9CaO5/Lv0PBaLQCWLMYh41usETP5XWpEvGWF+Y1d
mwCfSA9l2qR27DGT+tKi7MgrwUwKowc=
=Sgfb
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Calum <ca...@gmail.com>.

On 15 June 2011 18:54, Konstantin Kolinko <kn...@gmail.com> wrote:
> The request and response objects must never be accessed outside the
> request processing cycle.  The objects are recycled and cleared or
> reused for subsequent request and responses, and are not guaranteed to
> be thread-safe.  The consequences can be severe.

I was interested by this.
So:

    private Service service;

    @Override
    public void init() throws ServletException {
        super.init();
        service = (Service)
WebApplicationContextUtils.getWebApplicationContext(getServletContext()).getBean("service");
    }

    protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
            throws ServletException, IOException {
    service.logHit(request);
    ....
    }


is a bad thing?
Could you explain why?
I would assume that a new request object is created each time, and
that while something has a reference to it, it will be fine, and when
logHit has finished with it, it will be eligible for garbage
collection.


Calum

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Konstantin Kolinko <kn...@gmail.com>.

2011/6/15 Jocelyn Ireson-Paine <po...@j-paine.org>:
>     ResponseHolder rh = (ResponseHolder)this_session.getAttribute(
>  "response_holder" );
>     out.println( "rh = " + rh + ".<BR>" );
>     if ( rh == null ) {
>       out.println( "rh is null.<BR>" );
>       rh = new ResponseHolder( response );
>       this_session.setAttribute( "response_holder", rh );
>(...)
> If this a bug, is there any chance of getting it fixed, or of getting a
> circumvention? If I'm doing something bad, please tell me.
>

It is not a bug. It is just you doing something bad.

The request and response objects must never be accessed outside the
request processing cycle.  The objects are recycled and cleared or
reused for subsequent request and responses, and are not guaranteed to
be thread-safe.  The consequences can be severe.


There is a configuration option (a system property) that forces
recycling (zeroing) those objects, to spot misappropriate references
more easily.

http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Martin Gainty <mg...@hotmail.com>.

the error is here:
org.apache.catalina.connector.ResponseFacade.encodeURL(ResponseFacade.java:398) 
at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) if you look in /work/Catalina/localhost/WebAppName/org/apache/jsp/Test1_jsp.java 
at line 93 you will see the offending line

you are creating an artificial response object instead of using the response that is provided you via response
<% response.write("<em>this is a test in italics</em"); %>

hth
Martin Gainty 
______________________________________________ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.




> Date: Wed, 15 Jun 2011 18:43:21 +0100
> From: popx@j-paine.org
> To: users@tomcat.apache.org
> Subject: Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
> 
> About a week ago, I reported what seemed like a sporadic null-pointer 
> exception from response.encodeUrl. I've managed to simplify the code that 
> provokes it, and will show it below. My original report, with details of 
> the Tomcat version and so on, is after this mail.
> 
> The error occurred in a large system I've written that uses servlets and 
> JSP. It enables users to analyse certain kinds of numerical data over the 
> Web, and uses sessions to hold information about those users currently 
> using the system. Below is a JSP page I've constructed that demonstrates 
> the error:
>    <%@ page import="javax.servlet.*,javax.servlet.http.*,salco.*"%>
> 
>    <HTML>
>    <HEAD>
> 
>    <TITLE>Test1</TITLE>
>    </HEAD>
> 
>    <BODY BGCOLOR=white>
> 
>    <H1>Test1</H1>
> 
>    <%
>       HttpSession this_session = request.getSession(true);
>       out.println( "this_session = " + this_session + ".<BR>" );
> 
>       out.println( "Date = " + new java.util.Date() + ".<BR>" );
> 
>       ResponseHolder rh = (ResponseHolder)this_session.getAttribute(
>    "response_holder" );
>       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>" );
>      }
> 
>      String result = "None yet";
>      try {
>        result = rh.response.encodeURL( "/Test1.jsp" );
>        out.println( "Encoded URL OK: result = " + result + ".<BR>" );
>      }
>      catch ( java.lang.NullPointerException e ) {
>        out.println( "Crashed while encoding URL: <BR>" );
>        e.printStackTrace( new java.io.PrintWriter(out) );
>      }
>    %>
> 
>    </BODY>
>    </HTML>
> 
> This page starts by obtaining an instance of HTTPSession by calling 
> request.getSession(true). This instance will have been created when the 
> user logs in for their current session, by another call of 
> request.getSession(true).
> 
> The page then displays the date and time so that you can check that in my 
> diagnostics, the times follow one another and I'm not repeating old 
> output. It then tries to obtain an instance of a class I've defined named 
> ResponseHolder, and does so by calling HttpSession.getAttribute. 
> ResponseHolder is a class I wrote specially for this demo, and has one 
> field, an HTTPServletResponse. In real life, I store users' session data 
> in instances with many fields, of which an HTTPServletResponse is one. 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.
> 
> If the ResponseHolder instance is null, it's probably because the page is 
> being loaded for the first time in the session. In that case, I create a 
> new ResponseHolder, and call HttpSession.setAttribute to store it.
> 
> The page also maintains and displays a count. This is solely for this 
> demo. As with displaying the time, it's a sanity check on the output. For 
> example, it confirms that I actually have reloaded the page.
> 
> The rest of the page calls encodeURL, and displays the result. If 
> encodeURL crashes with a NullPointerException, it catches this and 
> displays the stack trace instead.
> 
> By the way, the page has three imports. Two are for the javax.servlet 
> classes; the third is for my project classes.
> 
> Next, here's my ResponseHolder class:
>    package salco;
> 
>    import javax.servlet.*;
>    import javax.servlet.http.*;
> 
>    public class ResponseHolder
>    {
>      public HttpServletResponse response;
> 
>      public ResponseHolder( HttpServletResponse r )
>      {
>        this.response = r;
>      }
> 
>      public String toString()
>      {
>        return "[ResponseHolder " + this.response + "]";
>      }
>    }
> 
> As mentioned earlier, it has just one field, the HttpServletResponse.
> 
> Finally, I'll show output from three sets of transactions. To create 
> these, I logged into the system, thereby creating a new session as 
> explained above. I then loaded the JSP page, Test1.jsp, and kept reloading 
> it. (This was in Firefox 4.0.1; but browser and browser version are 
> probably not relevant. The error also occurs on Internet Explorer and 
> Google Chrome.) I then copied the page shown by the browser into a text 
> file, and appended new pages as I reloaded them. Here, then is my 
> output. It's long, so be warned; to get to the end, search for "END OF 
> OUTPUT":
> 
> (FIRST SESSION)
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@9be2b5.
> Date = Wed Jun 15 17:46:45 BST 2011.
> rh = null.
> rh is null.
> 
> count = 0.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@9be2b5.
> Date = Wed Jun 15 17:46:55 BST 2011.
> rh = [ResponseHolder org.apache.catalina.connector.ResponseFacade@9c176c].
> rh is not null.
> 
> count = 1.
> Crashed while encoding URL:
> 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:398) 
> at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
> at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
> java.lang.Thread.run(Unknown Source)
> 
> ----
> 
> (SECOND SESSION)
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
> Date = Wed Jun 15 17:50:22 BST 2011.
> rh = null.
> rh is null.
> 
> count = 0.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
> Date = Wed Jun 15 17:50:35 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@1f8bd0d].
> rh is not null.
> 
> count = 1.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
> Date = Wed Jun 15 17:50:46 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@1f8bd0d].
> rh is not null.
> 
> count = 2.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
> Date = Wed Jun 15 17:51:44 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@1f8bd0d].
> rh is not null.
> 
> count = 3.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Was OK up to and including count=94, then:
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
> Date = Wed Jun 15 17:53:53 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@1f8bd0d].
> rh is not null.
> 
> count = 95.
> Crashed while encoding URL:
> 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:398) 
> at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
> at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
> java.lang.Thread.run(Unknown Source)
> 
> ----
> 
> (THIRD SESSION)
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
> Date = Wed Jun 15 18:36:38 BST 2011.
> rh = null.
> rh is null.
> 
> count = 0.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
> Date = Wed Jun 15 18:36:53 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@121b59a].
> rh is not null.
> 
> count = 1.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
> Date = Wed Jun 15 18:37:05 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@121b59a].
> rh is not null.
> 
> count = 2.
> Encoded URL OK: result = /Test1.jsp.
> 
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
> Date = Wed Jun 15 18:37:17 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@121b59a].
> rh is not null.
> 
> count = 3.
> Encoded URL OK: result = /Test1.jsp.
> 
> Was then OK up to and including count=49, then:
> 
> Test1
> this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
> Date = Wed Jun 15 18:37:59 BST 2011.
> rh = [ResponseHolder 
> org.apache.catalina.connector.ResponseFacade@121b59a].
> rh is not null.
> 
> count = 50.
> Crashed while encoding URL:
> 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:398) 
> at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
> at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
> java.lang.Thread.run(Unknown Source)
> 
> In this, the first session gave an error on the second use of the page, 
> i.e. the first reload. However, the second session didn't crash until the 
> 93rd reload, and the third, until the 49th.
> 
> If this a bug, is there any chance of getting it fixed, or of getting a 
> circumvention? If I'm doing something bad, please tell me.
> 
> Jocelyn Ireson-Paine
> http://www.j-paine.org
> http://www.spreadsheet-parts.org
> +44 (0)7768 534 091
> 
> Jocelyn's Cartoons:
> http://www.j-paine.org/blog/jocelyns_cartoons/
> 
> On Thu, 9 Jun 2011, Jocelyn Ireson-Paine wrote:
> 
> > 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 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.
> >
> > 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jocelyn,

On 6/20/2011 4:11 PM, Jocelyn Ireson-Paine wrote:
> I do put a reference to
> the response into an instance, in order that I can give my main
> processing method all the data it needs (including the response) as one
> single parameter. But I'd intended to put the response into this
> instance every time my JSP is accessed, and not merely the first time.
> Until you pointed it out, I didn't notice that I wasn't, even with my
> simplified code. So thanks for that.

No problem.

If you need all your data from scratch, anyway, why bother caching
anything at all? If your data is always ephemeral, these issues
evaporate and your code (often) becomes cleaner, too.

> That said, I think I was expecting that it wouldn't matter, since the
> response "ought" to be the same instance on each processing cycle
> anyway.

I would actually expect something different: that Tomcat always gives me
a brand new, never-before-used and never-to-be-used-again object. The
fact that Tomcat plays some tricks to reduce heap churn (that is,
allocating/initing/deallocating lots of "temporary" objects) should be
entirely transparent to the webapp if it's playing by the rules. The
servlet spec clearly states that the request and response objects are
only valid during a particular transaction.

> It's interesting to see why Tomcat violates the principle of
> least surprise - and I see it's still being discussed...

Ignorance of the spec will certainly cause a lot of "surprises" :)

I'm not convinced that this should be surprising, anyway.

If I write a method like this:

public void foo(Bar bar)
{
   ...
}

Why should the method foo() expect that each invocation will always have
the same Bar object passed-into it?

By extension:

public void doGet(HttpServletRequest req, HttpServletResponse rsp)
{
   ...
}

Should this one be treated any differently?

If the object is always going to be the same, why bother having it as a
parameter instead of part of the object's state?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/u7gACgkQ9CaO5/Lv0PBNzwCfY0SpILBVc49KPQn1gpjgVl2P
8YIAmwaX5CPtfQVdeicXoFW3j1B9tfwo
=FL9q
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

On Wed, 15 Jun 2011, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jocelyn,
>
> 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. ...
>
Christopher, and also Konstantin and Martin, thank you for your postings 
on this. As it happened, my original code that crashed, and from which I 
derived the demo code that I posted, had a bug. I do put a reference to 
the response into an instance, in order that I can give my main processing 
method all the data it needs (including the response) as one single 
parameter. But I'd intended to put the response into this instance every 
time my JSP is accessed, and not merely the first time. Until you pointed 
it out, I didn't notice that I wasn't, even with my simplified code. So 
thanks for that.

That said, I think I was expecting that it wouldn't matter, since the 
response "ought" to be the same instance on each processing cycle anyway. 
It's interesting to see why Tomcat violates the principle of least 
surprise - and I see it's still being discussed...

Jocelyn


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jocelyn,

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk35BDoACgkQ9CaO5/Lv0PAo+wCfbWC6nN1WAOftT3eqKGV/KJrA
ErEAn3Nzquxya6p+B7M5KCkjrGZOhFxl
=aJva
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

About a week ago, I reported what seemed like a sporadic null-pointer 
exception from response.encodeUrl. I've managed to simplify the code that 
provokes it, and will show it below. My original report, with details of 
the Tomcat version and so on, is after this mail.

The error occurred in a large system I've written that uses servlets and 
JSP. It enables users to analyse certain kinds of numerical data over the 
Web, and uses sessions to hold information about those users currently 
using the system. Below is a JSP page I've constructed that demonstrates 
the error:
   <%@ page import="javax.servlet.*,javax.servlet.http.*,salco.*"%>

   <HTML>
   <HEAD>

   <TITLE>Test1</TITLE>
   </HEAD>

   <BODY BGCOLOR=white>

   <H1>Test1</H1>

   <%
      HttpSession this_session = request.getSession(true);
      out.println( "this_session = " + this_session + ".<BR>" );

      out.println( "Date = " + new java.util.Date() + ".<BR>" );

      ResponseHolder rh = (ResponseHolder)this_session.getAttribute(
   "response_holder" );
      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>" );
     }

     String result = "None yet";
     try {
       result = rh.response.encodeURL( "/Test1.jsp" );
       out.println( "Encoded URL OK: result = " + result + ".<BR>" );
     }
     catch ( java.lang.NullPointerException e ) {
       out.println( "Crashed while encoding URL: <BR>" );
       e.printStackTrace( new java.io.PrintWriter(out) );
     }
   %>

   </BODY>
   </HTML>

This page starts by obtaining an instance of HTTPSession by calling 
request.getSession(true). This instance will have been created when the 
user logs in for their current session, by another call of 
request.getSession(true).

The page then displays the date and time so that you can check that in my 
diagnostics, the times follow one another and I'm not repeating old 
output. It then tries to obtain an instance of a class I've defined named 
ResponseHolder, and does so by calling HttpSession.getAttribute. 
ResponseHolder is a class I wrote specially for this demo, and has one 
field, an HTTPServletResponse. In real life, I store users' session data 
in instances with many fields, of which an HTTPServletResponse is one. 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.

If the ResponseHolder instance is null, it's probably because the page is 
being loaded for the first time in the session. In that case, I create a 
new ResponseHolder, and call HttpSession.setAttribute to store it.

The page also maintains and displays a count. This is solely for this 
demo. As with displaying the time, it's a sanity check on the output. For 
example, it confirms that I actually have reloaded the page.

The rest of the page calls encodeURL, and displays the result. If 
encodeURL crashes with a NullPointerException, it catches this and 
displays the stack trace instead.

By the way, the page has three imports. Two are for the javax.servlet 
classes; the third is for my project classes.

Next, here's my ResponseHolder class:
   package salco;

   import javax.servlet.*;
   import javax.servlet.http.*;

   public class ResponseHolder
   {
     public HttpServletResponse response;

     public ResponseHolder( HttpServletResponse r )
     {
       this.response = r;
     }

     public String toString()
     {
       return "[ResponseHolder " + this.response + "]";
     }
   }

As mentioned earlier, it has just one field, the HttpServletResponse.

Finally, I'll show output from three sets of transactions. To create 
these, I logged into the system, thereby creating a new session as 
explained above. I then loaded the JSP page, Test1.jsp, and kept reloading 
it. (This was in Firefox 4.0.1; but browser and browser version are 
probably not relevant. The error also occurs on Internet Explorer and 
Google Chrome.) I then copied the page shown by the browser into a text 
file, and appended new pages as I reloaded them. Here, then is my 
output. It's long, so be warned; to get to the end, search for "END OF 
OUTPUT":

(FIRST SESSION)

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@9be2b5.
Date = Wed Jun 15 17:46:45 BST 2011.
rh = null.
rh is null.

count = 0.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@9be2b5.
Date = Wed Jun 15 17:46:55 BST 2011.
rh = [ResponseHolder org.apache.catalina.connector.ResponseFacade@9c176c].
rh is not null.

count = 1.
Crashed while encoding URL:
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:398) 
at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
java.lang.Thread.run(Unknown Source)

----

(SECOND SESSION)

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
Date = Wed Jun 15 17:50:22 BST 2011.
rh = null.
rh is null.

count = 0.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
Date = Wed Jun 15 17:50:35 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@1f8bd0d].
rh is not null.

count = 1.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
Date = Wed Jun 15 17:50:46 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@1f8bd0d].
rh is not null.

count = 2.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
Date = Wed Jun 15 17:51:44 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@1f8bd0d].
rh is not null.

count = 3.
Encoded URL OK: result = /Test1.jsp.

Was OK up to and including count=94, then:

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@1ae9aaa.
Date = Wed Jun 15 17:53:53 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@1f8bd0d].
rh is not null.

count = 95.
Crashed while encoding URL:
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:398) 
at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
java.lang.Thread.run(Unknown Source)

----

(THIRD SESSION)

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
Date = Wed Jun 15 18:36:38 BST 2011.
rh = null.
rh is null.

count = 0.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
Date = Wed Jun 15 18:36:53 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@121b59a].
rh is not null.

count = 1.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
Date = Wed Jun 15 18:37:05 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@121b59a].
rh is not null.

count = 2.
Encoded URL OK: result = /Test1.jsp.

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
Date = Wed Jun 15 18:37:17 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@121b59a].
rh is not null.

count = 3.
Encoded URL OK: result = /Test1.jsp.

Was then OK up to and including count=49, then:

Test1
this_session = org.apache.catalina.session.StandardSessionFacade@c68a98.
Date = Wed Jun 15 18:37:59 BST 2011.
rh = [ResponseHolder 
org.apache.catalina.connector.ResponseFacade@121b59a].
rh is not null.

count = 50.
Crashed while encoding URL:
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:398) 
at org.apache.jsp.Test1_jsp._jspService(Test1_jsp.java:93) at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) 
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) 
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) 
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) 
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) 
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) 
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) 
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) 
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) 
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) 
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) 
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
java.lang.Thread.run(Unknown Source)

In this, the first session gave an error on the second use of the page, 
i.e. the first reload. However, the second session didn't crash until the 
93rd reload, and the third, until the 49th.

If this a bug, is there any chance of getting it fixed, or of getting a 
circumvention? If I'm doing something bad, please tell me.

Jocelyn Ireson-Paine
http://www.j-paine.org
http://www.spreadsheet-parts.org
+44 (0)7768 534 091

Jocelyn's Cartoons:
http://www.j-paine.org/blog/jocelyns_cartoons/

On Thu, 9 Jun 2011, Jocelyn Ireson-Paine wrote:

> 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 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.
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Null-pointer exception from response.encodeUrl under Windows Tomcat 7

Posted by Jocelyn Ireson-Paine <po...@j-paine.org>.

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 
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.

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: War file deployment deletes configuration descriptor in Tomcat 6

Posted by Dharamshila Khandelwal <dh...@gmail.com>.

I found that when it deletes the configuration descriptor, it doesn't deploy
it.
I am not able to understand why it is not deploying the descriptor


Logs from catalina.out:

*When the configuration descriptor is not deleted: *

Jun 8, 2011 4:31:45 PM org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context [/MOVE]
Jun 8, 2011 4:31:46 PM org.apache.catalina.startup.HostConfig
deployDescriptor
*INFO: Deploying configuration descriptor MOVE.xml*
Jun 8, 2011 4:31:46 PM org.apache.catalina.startup.HostConfig
deployDescriptor
WARNING: A docBase /opt/hsnweb/web94d/tomcat/webapps/MOVE inside the host
appBase has been specified, and will be ignored


*This is when configuration descriptor is deleted: *


Jun 8, 2011 4:44:18 PM org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context [/MOVE]
Jun 8, 2011 4:44:20 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive MOVE.war




On Wed, Jun 8, 2011 at 1:47 PM, Dharamshila Khandelwal <
dharmshila.k@gmail.com> wrote:

> Hi,
>
> Every time I deploy war file in webapps, it deletes the configuration
> descriptor which is present at $CATALINA_BASE/conf/[enginename]/[hostname]
> directory.
> Tomcat auto deploys war file in my Tomcat 6 configuration.
>
> How should I stop this problem?
>
> Any idea?
>
> Thanks,
> DS.
>
>