You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2013/01/30 12:41:48 UTC
Tomcat 7 - revision 1427821
Is anyone else seeing regressions due to this change?
They appear as NullPointerExceptions from java.io.Writer.write(String)
where the writer in question is a JSPWriter.
This was addressed long ago by the fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=35410, but the
revision reverts the fix as it is not specification compliant.
On the flip side, how do we know the fix was not specification
compliant? Did a new TCK reject this behavior? Or were other compliant
implementations found not to have this behavior? Or...?
I'm now left trying to figure out what to do about this change -- push
those which ran afoul of this to fix their code or patch the fix back
into our Tomcat.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 7 - revision 1427821
Posted by Mark Thomas <ma...@apache.org>.
On 30/01/2013 11:41, Jess Holle wrote:
> Is anyone else seeing regressions due to this change?
>
> They appear as NullPointerExceptions from java.io.Writer.write(String)
> where the writer in question is a JSPWriter.
>
> This was addressed long ago by the fix for
> https://issues.apache.org/bugzilla/show_bug.cgi?id=35410, but the
> revision reverts the fix as it is not specification compliant.
>
> On the flip side, how do we know the fix was not specification
> compliant? Did a new TCK reject this behavior? Or were other compliant
> implementations found not to have this behavior? Or...?
A more careful reading of the specification document
The complete logic chain is:
>From JSP.9.4.3
<%= obj %> => out.print(obj)
>From JSP.1.8.3
out is a JspWriter
>From the JspWriter#print(Object) Javadoc
The string produced by the java.lang.String.valueOf(Object) method is
written to the JspWriter’s buffer or, if no buffer is used, directly to
the underlying writer.
>From the implementation of java.lang.String#valueOf(Object)
return (obj == null) ? "null" : obj.toString();
So, obj.toString() is written to the JspWriter's buffer or, if no buffer
is used, directly to the underlying writer.
Writing to the underlying writer or buffer uses write(String)
write(null) triggers the NPE.
> I'm now left trying to figure out what to do about this change -- push
> those which ran afoul of this to fix their code or patch the fix back
> into our Tomcat.
The choice is yours but the view of the Tomcat committers is that apps
that hit this issue are not specification compliant.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 7 - revision 1427821
Posted by Jess Holle <je...@ptc.com>.
Thanks for the feedback.
It looks like our issues are tracing back to a single bad tag class
implementation.
On 1/30/2013 6:54 AM, Konstantin Kolinko wrote:
> 2013/1/30 Jess Holle <je...@ptc.com>:
>> Is anyone else seeing regressions due to this change?
>>
>> They appear as NullPointerExceptions from java.io.Writer.write(String) where
>> the writer in question is a JSPWriter.
>>
>> This was addressed long ago by the fix for
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=35410, but the revision
>> reverts the fix as it is not specification compliant.
>>
>> On the flip side, how do we know the fix was not specification compliant?
> 1. Mainly by carefully reading the specifications. In this case, the
> javadoc for JspWriter and PrintWriter as well as JSP spec.
>
> 2. The fix to BZ 35410 does not make much sense, as a proper way to
> print null value is "null", not "".
>
> 3. There is no way to distinguish <%= Object %> and <%= String %> and
> <%= int %> when generating Java code for a JSP page. The Java code
> will be the same.
>
> You can protect from your issue by explicitly using
> <%= String.valueOf(Object) %>
>
> In this case "String.valueOf(Object)" will take care of Object being
> null and out.print(String) will take care of String being null.
>
> but personally I would prefer to fix that toString() method.
>
>> Did a new TCK reject this behavior? Or were other compliant implementations
>> found not to have this behavior? Or...?
>>
>> I'm now left trying to figure out what to do about this change -- push those
>> which ran afoul of this to fix their code or patch the fix back into our
>> Tomcat.
>>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> 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: Tomcat 7 - revision 1427821
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/1/30 Jess Holle <je...@ptc.com>:
> Is anyone else seeing regressions due to this change?
>
> They appear as NullPointerExceptions from java.io.Writer.write(String) where
> the writer in question is a JSPWriter.
>
> This was addressed long ago by the fix for
> https://issues.apache.org/bugzilla/show_bug.cgi?id=35410, but the revision
> reverts the fix as it is not specification compliant.
>
> On the flip side, how do we know the fix was not specification compliant?
1. Mainly by carefully reading the specifications. In this case, the
javadoc for JspWriter and PrintWriter as well as JSP spec.
2. The fix to BZ 35410 does not make much sense, as a proper way to
print null value is "null", not "".
3. There is no way to distinguish <%= Object %> and <%= String %> and
<%= int %> when generating Java code for a JSP page. The Java code
will be the same.
You can protect from your issue by explicitly using
<%= String.valueOf(Object) %>
In this case "String.valueOf(Object)" will take care of Object being
null and out.print(String) will take care of String being null.
but personally I would prefer to fix that toString() method.
> Did a new TCK reject this behavior? Or were other compliant implementations
> found not to have this behavior? Or...?
>
> I'm now left trying to figure out what to do about this change -- push those
> which ran afoul of this to fix their code or patch the fix back into our
> Tomcat.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org