You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by fh...@apache.org on 2006/11/20 17:47:04 UTC

svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Author: fhanik
Date: Mon Nov 20 08:47:03 2006
New Revision: 477251

URL: http://svn.apache.org/viewvc?view=rev&rev=477251
Log:
TCK correction, depending on the sequence of the tests, the converter turns out to be null at certain times.
Added in a check to create the converter even when getting the output stream.


Modified:
    tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java?view=diff&rev=477251&r1=477250&r2=477251
==============================================================================
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java Mon Nov 20 08:47:03 2006
@@ -574,6 +574,7 @@
                 (sm.getString("coyoteResponse.getOutputStream.ise"));
 
         usingOutputStream = true;
+        outputBuffer.checkConverter();
         if (outputStream == null) {
             outputStream = new CoyoteOutputStream(outputBuffer);
         }



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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I don't see anything wrong with my fix, as it is clear that the 
outputstream is using the converter

java.lang.Exception: conv is null
        at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:471)
        at 
org.apache.catalina.connector.CoyoteOutputStream.print(CoyoteOutputStream.java:113)
        at 
javax.servlet.ServletOutputStream.println(ServletOutputStream.java:242)
        at 
com.sun.ts.tests.servlet.common.util.ServletTestUtil.printResult(ServletTestUtil.java:320)
        at 
com.sun.ts.tests.servlet.api.common.response.ResponseTests.flushBufferTest(ResponseTests.java:126)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at 
com.sun.ts.tests.servlet.api.common.response.ResponseTestServlet.service(ResponseTestServlet.java:43)
        at 
com.sun.ts.tests.servlet.api.javax_servlet.servletresponsewrapper.TestServlet.service(TestServlet.java:36)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
        at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:888)
        at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:624)
        at 
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1467)
        at java.lang.Thread.run(Thread.java:595)

Same test with the JIO connector
java.lang.Exception: conv is null
        at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:471)
        at 
org.apache.catalina.connector.CoyoteOutputStream.print(CoyoteOutputStream.java:113)
        at 
javax.servlet.ServletOutputStream.println(ServletOutputStream.java:242)
        at 
com.sun.ts.tests.servlet.common.util.ServletTestUtil.printResult(ServletTestUtil.java:320)
        at 
com.sun.ts.tests.servlet.api.common.response.ResponseTests.flushBufferTest(ResponseTests.java:126)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at 
com.sun.ts.tests.servlet.api.common.response.ResponseTestServlet.service(ResponseTestServlet.java:43)
        at 
com.sun.ts.tests.servlet.api.javax_servlet.servletresponsewrapper.TestServlet.service(TestServlet.java:36)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818)
        at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
        at java.lang.Thread.run(Thread.java:595)
                                                         

Filip

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> I figured :). I'll revert and hunt down the root cause. My guess is 
>> that if the response was used with output stream first, then recycled 
>> and then used again, somehow the conv ends up being null and causes a 
>> NPE in the write method.
>
> Ok, and what does the stack trace look like exactly ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> I figured :). I'll revert and hunt down the root cause. My guess is that 
> if the response was used with output stream first, then recycled and 
> then used again, somehow the conv ends up being null and causes a NPE in 
> the write method.

Ok, and what does the stack trace look like exactly ?

Rémy

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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> ok, here is what I found,
> 
> 
> CoyoteOutputStream.java
>    public void print(String s)
>        throws IOException {
>        ob.write(s);
>    }

I see. It's a mistake: this should be converted using the fixed default 
encoding (it works most of the time, but if somehow the app has set the 
encoding anyway, it might do funny things). Don't know what the best 
method would be, as there are some options, like using the superclass 
print(String).

Rémy

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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
ok, here is what I found,


CoyoteOutputStream.java
    public void print(String s)
        throws IOException {
        ob.write(s);
    }

This calls OutputBuffer.java
    public void write(String s)
        throws IOException {

        if (suspended)
            return;

        if (s == null)
            s = "null";
        conv.convert(s);
        conv.flushBuffer();

    }

and hence the NPE

Filip


Filip Hanik - Dev Lists wrote:
> I figured :). I'll revert and hunt down the root cause. My guess is 
> that if the response was used with output stream first, then recycled 
> and then used again, somehow the conv ends up being null and causes a 
> NPE in the write method.
>
> Filip
>
> Remy Maucherat wrote:
>> fhanik@apache.org wrote:
>>> Author: fhanik
>>> Date: Mon Nov 20 08:47:03 2006
>>> New Revision: 477251
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=477251
>>> Log:
>>> TCK correction, depending on the sequence of the tests, the 
>>> converter turns out to be null at certain times.
>>> Added in a check to create the converter even when getting the 
>>> output stream.
>>
>> I have to veto this. It's using the output stream in that case, so 
>> why does it matter if the converter (= the character encoder) is null ?
>>
>> Rémy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I figured :). I'll revert and hunt down the root cause. My guess is that 
if the response was used with output stream first, then recycled and 
then used again, somehow the conv ends up being null and causes a NPE in 
the write method.

Filip

Remy Maucherat wrote:
> fhanik@apache.org wrote:
>> Author: fhanik
>> Date: Mon Nov 20 08:47:03 2006
>> New Revision: 477251
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=477251
>> Log:
>> TCK correction, depending on the sequence of the tests, the converter 
>> turns out to be null at certain times.
>> Added in a check to create the converter even when getting the output 
>> stream.
>
> I have to veto this. It's using the output stream in that case, so why 
> does it matter if the converter (= the character encoder) is null ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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


Re: svn commit: r477251 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Posted by Remy Maucherat <re...@apache.org>.
fhanik@apache.org wrote:
> Author: fhanik
> Date: Mon Nov 20 08:47:03 2006
> New Revision: 477251
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=477251
> Log:
> TCK correction, depending on the sequence of the tests, the converter turns out to be null at certain times.
> Added in a check to create the converter even when getting the output stream.

I have to veto this. It's using the output stream in that case, so why 
does it matter if the converter (= the character encoder) is null ?

Rémy

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