Bugzilla – Full Text Bug Listing
| Summary: | [validation] JSP syntax validator requires brackets after IF statement | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Ian Tewksbury <itewksbu> | ||||||||
| Component: | jst.jsp | Assignee: | Ian Tewksbury <itewksbu> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Nitin Dahyabhai <thatnitind> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | ccc, nsand.dev | ||||||||
| Version: | 1.5.5 | Flags: | nsand.dev:
review+
|
||||||||
| Target Milestone: | 1.5.5 P | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 150685 [details]
Fix Patch
This patch fixes the problem by collecting all "non translated" code from the
JSP document and appending it to the translated virtual Java document striping
out white-space and placing it in an "out.print" statement. The "non
translated" code is collected for one "out.print" statement until some part of
the JSP is actually translated and is about to be written to the virtual Java
document, when that is about to happen is when the collected non-translated
code (such as HTML tags) is put into the buffer.
The result of the translation is now:
try {
out.print("<%@pagelanguage=javacontentType=text/html;charset=ISO-8859-1pageEncoding=ISO-8859-1%><!DOCTYPEhtmlPUBLIC-//W3C//DTDHTML4.01Transitional//ENhttp://www.w3.org/TR/html4/loose.dtd><html><head><metahttp-equiv=Content-Typecontent=text/html;charset=ISO-8859-1><title>Inserttitlehere</title></head><body><selectname=horoscope><optionvalue=Aries>Aries</option>");
if(true)
out.print("%><optionvalue=>All_users</option></select></body></html>");
} catch (java.lang.Exception e) {}
with no validation errors reported.
Created attachment 150721 [details]
Fix Patch Update 1
All the string manipulation to write the non translated code to the virtual Java document is expensive and does not buy us anything, so instead this patch just writes an empty out.print("") expression as a place holder. The translation now looks like:
...
try {
out.print(""); //non translated code placeholder
if(true)
out.print(""); //non translated code placeholder
} catch (java.lang.Exception e) {}
...
(In reply to comment #2) > Created an attachment (id=150721) [details] > Fix Patch Update 1 > > All the string manipulation to write the non translated code to the virtual > Java document is expensive and does not buy us anything, so instead this patch > just writes an empty out.print("") expression as a place holder. The > translation now looks like: > > ... > try { > out.print(""); //non translated code placeholder > if(true) > out.print(""); //non translated code placeholder > } catch (java.lang.Exception e) {} > ... I think this is a much better solution. One thing that's a little different than expected is that I seem to be getting out.print("")s for custom tags like <c:out value="foo"></c:out> (one for both the start and end tag of it). I think this also happens for <% String foo = "blah"; %>, you'd end up with extra out.prints. Any way we could minimize this? (In reply to comment #3) > I think this is a much better solution. One thing that's a little different > than expected is that I seem to be getting out.print("")s for custom tags like > <c:out value="foo"></c:out> (one for both the start and end tag of it). I think > this also happens for <% String foo = "blah"; %>, you'd end up with extra > out.prints. Any way we could minimize this? It was a long time ago but I vaguely remember discussing this with you and I don't remember the reason off the top my head but I do remember that only the minimum number of out.pints that can be output for this to work are being output. But I can apply the patch again and figure out what this reason is again for you if you would like. Created attachment 154716 [details]
Fix Patch Update 2
Fixed it so that %> would be considered "translated code" even though its not
actually translated into anything.
Patch looks good to me. Thanks, Ian. Committed to R1_5_5_patches |
Currently the following: ... <select name="horoscope"> <option value="Aries">Aries</option> <%if(true)%> <option value="">All_users</option> </select> ... is translated as: ... try { if(true) } catch (java.lang.Exception e) {} }} .. The java validator then reports the error "Syntax error on token ")", Statement expected after this token" which then in turn gets reported on the JSP. The JSP is using legal syntax and thus the validation error should not be reported.